-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decoupled TAN: "Got neither 3956 nor HITAN with tanProzess=2" #412
Comments
Okay let's see. Starting on PDF page 37 in section "B.4.2.2.1 Einfach-Sicherheitsfreigabe bei Prozessvariante 2", in step 2c, we today only support the "(B)" branch. However, the response that your bank sends isn't the "(A)" branch either:
The response you posted only contains only one HITAN overall, not two. So there's the following possible explanations:
|
Thank you for your quick and detailed response. I also checked B.4.2.2.1 and absolutely agree that there should be another HITAN with I've attached a log of a full flow for a getStatementOfAccount which needs a TAN since the startdate is more than 3 months in the past. So to answer you suggestions:
But maybe it seems i have to check with the bank... |
Maybe the "bug" is a widely accepted deviation from the specification, perhaps because many people missed that part in the spec or because they didn't bother to implement it that strictly (ignoring an extra segment could be the default behavior depending on how the code base is structured). Short of asking the bank, perhaps you could try the same or a similar sequence of messages/commands with a different FinTS client, and specifically client that also allows you to log the requests and responses. Then we can see whether that client receives the same response (and interprets it differently) or whether it receives a different response (due to having sent a different kind of request, in which case we'd have to look more closely on the request side). |
Is there a way to fix this? Got this too for blz 55090500 |
run in this BUG month later on Sparkasse ... and the solution is ... ? |
We need to figure out what the right way forward is. Since it seems to be a deviation from the specification, we should go with the herd, i.e. try to do what everyone else is doing. And because it's not specified, we need to figure it out experimentally.
|
Same on 35650000. Rlly frustrating, Sparkasse has completly turned off pushTAN 1.0 and only 2.0 (decoupled) is possible. Whole Banking function not work any more. Is there anything i could do to speed up this task? |
Maybe this helps, the TAN segment that was returned on checkDecoupledSubmission is "S" (const TAN_PROZESS_S). Then, line 488 there was no outstanding part found, setTanRequest is called but no action after that? The author wrotes "At the moment we solve the issue in checkDecoupledSubmission() by also setting $isSuccess to true if the HITAN is a HKTAN::TAN_PROZESS_S" but this doesnt help, because the origin request (where the tan was requested for) is not executed! |
This bank also glosses over another part of the specification: In Schritt 1a, it mandates that the response from the bank contain either |
Ah so you have the opposite experience? Because @witschko noticed this error message "as part of a successful response" and explicitly confirmed "I'm sure the authorization is done because I'm getting a positive response with the statements included". And in your case, you say you get a response that is not success (no HIRMS), but also doesn't contain 3956 (which would indicate that the authentication is still pending)? Would you be able to post the response message you're receiving and ideally also the corresponding request that you sent? Similar to the decoupled.log files posted above -- be sure to erase sensitive details from it, without changing the length of the message, i.e. replace sensitive characters with |
I'm sorry, maybe it was not clear enough.
I'm pretty sure the request as @witschko wrote is success. I've forked the repo and modify the code on checkDecoupledSubmission. $isSuccess is not true because HKTAN::TAN_PROZESS_S was found in segment (i only describe the function not the underlaying data (dont know about this)). After that the code in "else" was executed. The check on $response->findRueckmeldungen(Rueckmeldungscode::STARKE_KUNDENAUTHENTIFIZIERUNG_NOCH_AUSSTEHEND) was FALSE! Therefore there is no authentication required and the setTanRequest is set. But as you can see not the processActionResponse (not part of code). On my modification i'm execute processActionResponse anyway and the result is what i need. On the origin code i got the message "there was no tan needed for this action" and its aborting if i serialize the action. With this modification it works for the moment, but i known is little bit "hacky". I've try to extract these details from log, but needs some time (due missing sandbox and must wait for some customer to execute these steps) |
there you go - hope it will help. |
Perfect, thanks! Side remark: This bank also doesn't send 0030 alongside the 3955. I guess it's good that phpFinTS never insisted on this part of the spec. It's great that your record also includes a 3956 ("not yet confirmed") response for contrast. In fact, even two of them. And then on the third status query, the confirmation is done and the server delivers the result. And as you say, it's a successful result, HIRMS is present. And as suspected, they send only HITAN(S) but not the HITAN(2) that the specification also demands. So we have to infer from the absence of 3956 alone that the authentication is complete. And complete can mean successful or permanently failed, and we can infer from the presence of the result HIRMS that it was a success in this case. Please try this patch: Philipp91@3b32a2a It should be equivalent to what you did, but less hacky. |
Thank you very much for the patch. Quick tests on this, 1/2 banks accept this. I'll try to post another log for the bank who doesnt, asap. |
I also ran in this problem with TAN method 923 on an account from "Sparkasse Pforzheim Calw" (PZHSDE66XXX) To force the TAN necessity I set quite a long time range when creating \Fhp\Action\GetStatementOfAccount (for example a whole year) and then do $fints->execute. However: I will happily provide log files on this if you guys can quickly tell me how to gather relevant information for proper debugging? This is really not my field of expertise... |
Just wanted to let you know - I just tested this patch and it is working fine on the Sparkasse accounts I have access to. |
Yes can confirm that Sparkasse works. On some Volksbank accounts it doesnt, will send log soon. |
Hey everybody,
i've been testing the decoupled TAN process with two different banks (Kreissparkasse and VR). It seems the current implementation doesn't work with both of them. Both only send
HKTAN::TAN_PROZESS_S
and DO NOT sendHKTAN::TAN_PROZESS_2
as part of a successful response (examples are attached to this issue).But the current implementation assumes that only messages that contain the
HKTAN::TAN_PROZESS_2
have been confirmed by the user successfully. It seems that is not correct at least for KSK and VR banks.At the moment we solve the issue in
checkDecoupledSubmission()
by also setting$isSuccess
to true if the HITAN is aHKTAN::TAN_PROZESS_S
but still checking if it is an outstanding message and returning false if so.But I'm not sure if this is the final way to go...any help is very appreciated.
decoupled.log
The text was updated successfully, but these errors were encountered: