Automatic handling of FinTS system IDs?

[e7p]

Recently, Uploads from Sparkasse led to mandatory TAN entry which certainly should not be required for fetching transactions. Now that python-fints has a system_id argument, this helps to keep a session (longer) open and not having to enter a TAN every time.

Wouldn't it be good, if the system ID would be added into the configuration whenever it updates? And then to reuse it upon the next connection to the bank?

[raphaelm]

Yup, that would be great! I knew I forgot something in my chain of changes yesterday :D The only downside/challenge is that pretix-banktool is so far stateless and has no obvious place to store this in. Still, would be a good change.

I currently don't have any events running with a Sparkasse account (and know of no paying pretix customers who use this tool), so it's hard to proritize it but it shouldn't be too hard either, I'll have a look if I have time, unless someone else creates a PR first :)

[e7p]

Yes, I also thought about the missing state, and thought about the potential sensitivity of that value. Such things should be stored as secure as the configuration file. And I also see that updating the configuration from within the application is also not the best way to do it, even though it'd be the best effort.

I might have a look at it as well if there is the need for it. First, I will test if the system ID ever changes (Labortage presale is still running, so I'll just let it run until the event and then evaluate). If not, then I guess it would be the best to simply prompt the user if it is not (yet) set or had changed, and then it would need to be updated in the config. So many "woulds", but I'm not too much into this project, so let's see.

[raphaelm]

The FinTS spec suggests that it may change, specifically if no connection was made for 6 months the bank is allowed to forget the system ID and issue a new one. That's the intentional case listed in the spec but I'm hesitant to believe it's the only one.

I think if we put it in the config file we could at least offer a flag to enable auto-updating of the value to make usage easier.

[raphaelm]

That said, if we'd find another way to store state that makes us happy, there would be other uses as well. For example, for some banks it would be advisable to block any further non-interactive invocations after the 90 day TAN-less window is over, since any further attempt to connect will count towards a limit of three attempts after which the account is locked until you call the bank. (Observed with Triodos Bank, but may affect all Volksbanken as well since it's all run by Atruvia.)

[e7p]

That said, if we'd find another way to store state that makes us happy, there would be other uses as well. For example, for some banks it would be advisable to block any further non-interactive invocations after the 90 day TAN-less window is over, since any further attempt to connect will count towards a limit of three attempts after which the account is locked until you call the bank. (Observed with Triodos Bank, but may affect all Volksbanken as well since it's all run by Atruvia.)

That would be of course the best. At least for Sparkasse Bochum I can say that on 25 consecutive days trying it without an entered TAN they didn't block anything. However, I see that other banks handle stuff differently. Interesting to see how flexible and not well-defined the protocol seems to be (well, it makes sense historically).