Enable FinTS persistence

[JuliusFreudenberger]

As discussed in #149, storing and loading the FinTS persistence string can prevent needing to enter a TAN on every import run. I also have this problem, since my Sparkasse switched to decoupled TAN submission (which I provided as a feature in #142 and #145).

This PR adds several things:

• It presents the base64 enconded persistence string in the Done step at the end of an import run with a description to add it into the configuration.
• If the persistence string present in the JSON, it is decoded and loaded in the CollectData step and added to the constructor of the FinTS instance.
• Some description in the Readme in the configuration paragraph.

For me, this works so that I do not have to approve the importer again and again on every run.
I also verified that everything works in a freshly built docker image with the current php-FintTS version specified by composer.

[niklas152]

Hey there Julius,

first of all thank you for your work, I am facing the same problem.
However for me this does not work, maybe you have got an idea why not:
My bank is the DKB and I am using tan mode 940, thus verifying in the app that the request is from me.
With your PR, I get presented a persistency string and when I add it to the config it seems to be using it (the first time I made an copy error and it complained that it got a string but couldn't parse it, thus I am now quite sure it gets it + parses it).
Sadly, I am still being asked for a TAN and at the end it presents me a new persistency string, which only differs in a few place towards the end - decoding the base64 give me that it's really at the far end:
i:7;s:30:"<this value changes, it's of the format DKB_ followed by an apparently random string that seems to be different everytime>";i:8;i:5;}
Any idea what and why that is, maybe even how I can fix that?

Thank you and best regards
Niklas

[JuliusFreudenberger]

Hi Niklas,
first of all: When it does not complain anymore I also think it is safe to say it correctly parses the string. It is base64 encoded, as otherwise I had problems with encoding of umlauts while copy-pasting. Base64 ensures the string only contains ASCII-characters. The string that comes out is php serialized text for an object. What you gave me is part of an object that has an integer 7 and a string with length 30 and two other integers.
I really have no expertise in FinTS and PHP, I more or less hacked this code together (in fact, my two previous PRs were the first time I wrote PHP). However, maybe we can come up with a solution together.
Can you tell me if this string that is always changing is the kundensystemId of the fin_ts object? Because that is really the necessary part that we need here (at least it is the case for Sparkasse).

[niklas152]

Hey,

thanks for the amazingly fast reply!

I am also not proficient in PHP at all, but from your message and https://github.com/nemiah/phpFinTS/blob/874bda56f15333e699c4d89a940cdab4599a4efe/lib/Fhp/FinTs.php#L210 I would guess the changing string is dialogId - kundensystemId appears to be stable.

[JuliusFreudenberger]

I also investigated and came to the same conclusion, my end of the decoded string looks quite similar and the corresponding string deserialized into the dialogId. However, this makes me wonder, as I forget the dialog after the persistence string was loaded into the fin_ts object. This sets the dialogId to null, so this should really not matter.

While reading some of the functions' documentation it appeared to me, that:

1. there is a minimal flag. By default it is false, but when set the kundensystemId is still persisted. So I guess this could make the persistence string much smaller while keeping the functionality.
2. When the statements where fetched from the bank (and thus the TAN request is already handled), the FinTS connection should be closed and thus the user logged out.

This does not seem related for your problem, but we are talking about banks here, so maybe it matters...?
I'll try to integrate these changes and then you can give it another try. If this does not help, then I am out of ideas because I am not really deep in the whole FinTS-topic. So maybe opening an issue/commenting in the existing issue in the phpfints repo may be an idea.

[niklas152]

Okay, sounds good, thank you :)

Just to check, for you this works in that the firefly fints importer doesn't even ask for a tan? Or how does the "working" state of this look?

[JuliusFreudenberger]

I could not get it to work with the minimal persistence string, as that requires fetching the tan modes again and that would need a bit more refactoring I am willing to currently do. Maybe I'll investigate that further.

To answer your question: Yes, that is what happening for me. Once I chose my TAN device (which is "Alle Geräte"/all devices) because of the decoupled TAN submission), I do not have to confirm in the TAN app or anything and the importer directly continues to "The connection to your bank was tested sucessfully."
If I omit the persistence string, I get requested to confirm in the TAN app.

[niklas152]

Hmm. I don't even get the select your tan device screen (instead it has a auto continuing screen that says "Your chosen tan mode does not require you to choose a device.")
Then it goes on and I get a tan request.

[JuliusFreudenberger]

Choosing a tan device is bank specific, so this does not necessarily mean that this is not intended. Do you get a decoupled tan request or a synchronous one?

[niklas152]

Either way, thank you a lot for your quick replies and the jump into immediatly troubleshooting something that really is only tangntial to your PR :D

[niklas152]

Choosing a tan device is bank specific, so this does not necessarily mean that this is not intended. Do you get a decoupled tan request or a synchronous one?

From the de-serialized persistence object I would guess a decoupled one, at least that string appears a few times in there.

[niklas152]

Incorperating the last commit of yours, i.e., the closing, seems to now set the dialog id to null (as expected). Interestingly, this also changes the messageNumber from 5 to 6.
Sadly, using the corresponding persistence string in the config still yields the same result, I get asked the TAN :(
Maybe it's a DKB thing? We'd probably need someone else to try that.

[JuliusFreudenberger]

I would guess a decoupled one

Much easier to find out: Do you get a text input or do you confirm using your tan method and the just hit continue in the importer?

Maybe it's a DKB thing? We'd probably need someone else to try that.

It surely is, and I sadly cannot test this as I am not a DKB customer.

[niklas152]

Much easier to find out: Do you get a text input or do you confirm using your tan method and the just hit continue in the importer?

The latter. It tells me to confirm, I confirm in the DKB app and then can press continue on the fints-importer.

It surely is, and I sadly cannot test this as I am not a DKB customer.

Yeah, makes sense. Maybe someone else will come a long, eventually. Again, thanks for your help so far!

[JuliusFreudenberger]

Yeah, makes sense. Maybe someone else will come a long, eventually. Again, thanks for your help so far!

At least its comforting to know it could potentially work for other banks but most importantly did not break anything for you. Even if the import process is kind of cumbersome this way.

[niklas152]

No absolutely, the issue was introduced by some change on DKBs side. On the contrary, your implementation for decoupled tan entry made the it work at all again, that persistent tan isn't working is annoying but very likely not your fault :D
Given that, I am currently considering re-implementing the behavior of this project in a language I am more familiar with, currently eyeing https://github.com/raphaelm/python-fints
Maybe that is also interesting to you, albeit this project is now working again for you.

[JuliusFreudenberger]

On the contrary, your implementation for decoupled tan entry made the it work at all again, that persistent tan isn't working is annoying but very likely not your fault :D

I'm happy it also helped you :)

Given that, I am currently considering re-implementing the behavior of this project in a language I am more familiar with, currently eyeing https://github.com/raphaelm/python-fints Maybe that is also interesting to you, albeit this project is now working again for you.

I'm surely interested. But I think this now gets way out of scope of this PR, so make sure to contact me if you really start working on that.

[bnw]

Hi @JuliusFreudenberger,

thank you so much for your contribution! The code is already looking good.

If I understand it correctly, the change needs an update in the fints library, correct?
Could you include an updated composer.lock in the PR that reflects this?
When doing so, please try to update as few libraries as possible.
Also, when updaing the library, can you assess if there are any breaking changes incoming that could cause problems for this importer?

Thanks a lot :)

[JuliusFreudenberger]

Hi @bnw,

no, there is no update necessary. A freshly built docker image based on this branch works perfectly for me. Sadly it does not fix it for DKB imports as we found out above.
During my testing, I could not make out breaking changes.

[niklas152]

@JuliusFreudenberger There likely isn't a fix for DKB, as the behavior seems to be intentional, sadly (more details here).

[bnw]

no, there is no update necessary. A freshly built docker image based on this branch works perfectly for me.

I see. Thanks a lot then :)