How to correctly handle persisting FinTs

[ampaze]

I have something like this:

try {
    $currentAction = $fints->login();
    $currentAction->ensureDone();
    if ($currentAction instanceof DialogInitialization) {
        $currentAction = $work;
        $fints->execute($currentAction);
        $currentAction->ensureDone();
    }
}  catch (TanRequiredException|ActionPendingException|VopConfirmationRequiredException $e) {
    return $this->handleFinTsInterruptionException(...);
} catch (ServerException $e) {
    return $this->informUserOfError(...);
} finally {
    //storeToSession();
}
$fints->close();
//storeToSession();

This stores FinTs to the session no matter what. Using the state from the session works fine when dealing with VoP and TAN.

The problem comes when reusing the persisted state for the next action/Geschäftsvorfall.
In this case I call login() again, even though I might still be logged in. (Which then results in Die Nachricht hat nicht die erwartete Nachrichtennummer.)

How would I check if I need to login again? As the user can close the browser at any time, close() might not get called.

[Philipp91]

We could add hasDialog() { return $this->dialogId !== null; }.

That said, I think you should be in control of whether the session is active or not. So whenever you "exercise that control", i.e. change the state of the session, you could flip an auxiliary bit in the same database where you also store the persisted instance. Though I see the convenience of using $this->dialogId !== null as the extra bit, so it's less coding effort in the application code.

As the user can close the browser at any time, close() might not get called.

In such a scenario, in order to be properly in control, you should either (a) run some cron job that closes connections that haven't been used for x minutes, or (b) upon resume assume that sessions unused for more than x minutes are gone (and call $fints->forgetDialog() so that $fints->login() is definitely the right call after that).

A problem with both of these approaches would be figuring out the "x minutes". One solution could be to define the number of minutes yourself (and tell your users about it, e.g. you can then even display an auto-logout timer on your UI) and in order to make it the truth, you have a higher-frequency cron job that sends keep-alive messages for any sessions that it assumes are still active (and haven't sent a message within the last minute anyway), until your defined timeout is reached, at which point the cron job actively closes the session. Keep-alive is defined in FinTS_3.0_Formals_2017-10-06_final_version.pdf chapter C.9, should be relatively easy to implement, and has been enquired about before.

Another solution would be to assume "x" is HIBPAv3::$maximalerTimeoutWert, which we could expose through the BPD API. If in your DB you bump a timestamp for when you received the last message from the server, then by comparing that plus this timeout against the current time you can decide whether you should call forgetDialog() and login() or whether to assume the previous dialog is still active and you can continue using it.

[ampaze]

We could add hasDialog() { return $this->dialogId !== null; }.

I am not sure this would help, dialogId would still be set after resuming FinTs from persisted data.

Another solution would be to assume "x" is HIBPAv3::$maximalerTimeoutWert, which we could expose through the BPD API. If in your DB you bump a timestamp for when you received the last message from the server, then by comparing that plus this timeout against the current time you can decide whether you should call forgetDialog() and login() or whether to assume the previous dialog is still active and you can continue using it.

I checked with my bank, unfortunately these values are not set:

Fhp\Segment\HIBPA\HIBPAv3 Object
(
   ...
    [minimalerTimeoutWert] => 
    [maximalerTimeoutWert] => 
)

---

Maybe it would be better to just try to send a small action that requires a login and react accordingly if the bank answers with "not logged in" or some other error.

Also, is it really required to start login with Nachrichtennummer 1?

[Philipp91]

With the exception of these keep-alive messages, the Nachrichtennummer sequence must be strictly ascending by +1 each message. I don't see how that would be a problem though. If you just probe the bank with some action (I suggest the keep-alive action for this), then it will either respond with OK (and then the dialogId and sequence number you have stored are both still valid) or it will say "unknown dialog" (it won't say "not logged in") in which case you can throw away all the dialog/sequence information you had and start a fresh dialog with login().

[ampaze]

The keep-alive message would have to be implemented in FinTs and cannot be done with execute(), because the Nachrichtennummer must not be increased for these messages. Correct?

Or I could just try to send the action that I want to send anyway and react to the not logged in message then.

[Philipp91]

Yes and yes.

[ampaze]

For anyone interested, this is my current solution.

The only downside is if you send a lot of data with your action, it will might be sent twice. This could be solved with the Keep-Alive-Message discussed above.

class FinTsSessionAware extends FinTs
{
    public function storeToSession(): void
    {
        // Implement this yourself
    }

    public function hasDialog(): bool
    {
        return $this->dialogId !== null;
    }

    public function loginIfNeededAndExecute(BaseAction $action): BaseAction
    {
        $logger = $this->getLogger();
        $loginNeeded = false;
        if ($this->hasDialog()) {
            // Probieren ob wir vlt noch eingeloggt sind
            $currentAction = $action;

            try {
                $logger->info('Executing ' . get_class($currentAction));
                $this->execute($currentAction);
            } catch (ServerException $e) {
                if ($e->hasError(Rueckmeldungscode::ABGEBROCHEN)) {
                    $loginNeeded = true;
                } else {
                    // Something else went wrong.
                    throw $e;
                }
            }
        } else {
            $loginNeeded = true;
        }

        if ($loginNeeded) {
            $logger->info('Calling login()');
            $currentAction = $this->login();
            $currentAction->ensureDone();

            // Login ist erfolgt, also eigentliche Action ausführen
            if ($currentAction instanceof DialogInitialization) {
                $currentAction = $action;
                $logger->info('Executing ' . get_class($currentAction));
                $this->execute($currentAction);
            }

        }
        return $currentAction;
    }

}

[Philipp91]

Cool, thank you!

Nit-pick review comment: $loginNeeded can be removed entirely after inserting return $currentAction after the first execute.

And storeToSession() doesn't appear to be called.

[ampaze]

Nit-pick review comment: $loginNeeded can be removed entirely after inserting return $currentAction after the first execute.

Good point!

storeToSession is called from outside, like I outlined in the first post. It would be nice to have a callback inside of FinTs that gets called on every state change, so on every message sent and every response received/processed.