Kein gültiges Sicherheitsprofil. (9930)

[djm03]

Guten Tag,

mit dem dev-master von gestern konnte ich heute das erste mal wieder abrufen. Jetzt habe ich erneut das letzte Update eingespielt und erhalte beim Abruf:

[HIRMG] 3060: Bitte beachten Sie die enthaltenen Warnungen/Hinweise. [HIRMS] 3050: BPD nicht mehr aktuell, aktuelle Version enthalten. [HIRMS] 3920: Zugelassene Zwei-Schritt-Verfahren für den Benutzer. [HIRMS] 0020: Der Auftrag wurde ausgeführt. [HIRMS] 3076: Starke Kundenauthentifizierung nicht notwendig. Received dialog ID: ...=...= DIALOG end

HKSPA (SEPA accounts) initialize ... [HIRMG] 9050: Die Nachricht enthält Fehler. [HIRMG] 9800: Dialog abgebrochen [HIRMG] 9930: Kein gültiges Sicherheitsprofil. [HIRMS] 9010: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. Request Failed: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Kein gültiges Sicherheitsprofil. (9930) Request Failed: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Kein gültiges Sicherheitsprofil. (9930)

Hat jemand einen Tipp für mich? Danke!

[nemiah]

Hallo @djm03! Bitte probier es jetzt nochmal.

[djm03]

Hi nemiah, die Meldung ist die gleiche :/

[na-oma]

Bei der Ostsächsischen Sparkasse erhalte ich mit der aktuellen dev-master ähnliches.

Mit dev-master 25d05350ad56b20ddc2c1435126561f6f91141fa von vor 2 Tagen funzt es aber:

$fints = new FinTs();
$accounts = $fints->getSEPAAccounts();

Damit geht auch getStatementOfAccount, getStatements, getTransactions

Wenn ich dann auf dev-master 0c41d10d3d3a79bd8478baca2d03be16bab4a538 upgrade (deinem merge direkt danach, auch von vor 2 Tagen) kommt schon bei getSEPAAccounts ein Fehler:

[2019-09-18 18:53:59] name.INFO: HKSPA (SEPA accounts) initialize [] [] [2019-09-18 18:53:59] name.ERROR: [HIRMG] Die Nachricht enthält Fehler. [] [] [2019-09-18 18:53:59] name.ERROR: [HIRMG] Dialog abgebrochen [] [] [2019-09-18 18:53:59] name.ERROR: [HIRMG] Falsche Segmentzusammenstellung [] [] [2019-09-18 18:53:59] name.ERROR: Request Failed: Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Falsche Segmentzusammenstellung (9110) [] [] [2019-09-18 18:53:59] name.CRITICAL: Request Failed: Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Falsche Segmentzusammenstellung (9110) [] []

Mit dem eingeführten $fints->setTANMechanism(920, 'Script'); (egal welchen) vorher kommt der o.g. Fehler:

[2019-09-18 19:06:38] name.INFO: HKSPA (SEPA accounts) initialize [] [] [2019-09-18 19:06:38] name.ERROR: [HIRMG] 9050: Die Nachricht enthält Fehler. [] [] [2019-09-18 19:06:38] name.ERROR: [HIRMG] 9800: Dialog abgebrochen [] [] [2019-09-18 19:06:38] name.ERROR: [HIRMG] 9930: Kein gültiges Sicherheitsprofil. [] [] [2019-09-18 19:06:38] name.ERROR: [HIRMS] 9010: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. [] [] [2019-09-18 19:06:38] name.ERROR: Request Failed: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Kein gültiges Sicherheitsprofil. (9930) [] [] [2019-09-18 19:06:38] name.CRITICAL: Request Failed: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Kein gültiges Sicherheitsprofil. (9930) [] []

Wenn ich auf den aktuellen dev-master (dev-master 02726bdc39449dbd82a31dfb0a3bef495c01c98f) gehe, und ebenfalls TAN-Mechanismus setze, bekomme ich o.g. Fehler:

[2019-09-18 19:00:24] name.INFO: Supported TAN mechanisms: chipTAN manuell (910), chipTAN optisch (911), chipTAN-USB (912), chipTAN-QR (913), smsTAN (920), pushTAN (921), iTAN (900) [] []

[2019-09-18 19:00:24] name.WARNING: [HIRMG] 3060: Bitte beachten Sie die enthaltenen Warnungen/Hinweise. [] [] [2019-09-18 19:00:24] name.WARNING: [HIRMS] 3050: BPD nicht mehr aktuell, aktuelle Version enthalten. [] [] [2019-09-18 19:00:24] name.WARNING: [HIRMS] 3920: Zugelassene Zwei-Schritt-Verfahren für den Benutzer. [] [] [2019-09-18 19:00:24] name.INFO: [HIRMS] 0020: Der Auftrag wurde ausgeführt. [] [] [2019-09-18 19:00:24] name.WARNING: [HIRMS] 3076: Starke Kundenauthentifizierung nicht notwendig. [] [] [2019-09-18 19:00:24] name.INFO: [] [] [2019-09-18 19:00:24] name.INFO: HKSPA (SEPA accounts) initialize [] [] [2019-09-18 19:00:24] name.ERROR: [HIRMG] 9050: Die Nachricht enthält Fehler. [] [] [2019-09-18 19:00:24] name.ERROR: [HIRMG] 9800: Dialog abgebrochen [] [] [2019-09-18 19:00:24] name.ERROR: [HIRMG] 9930: Kein gültiges Sicherheitsprofil. [] [] [2019-09-18 19:00:24] name.ERROR: [HIRMS] 9010: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. [] [] [2019-09-18 19:00:24] name.ERROR: Request Failed: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Kein gültiges Sicherheitsprofil. (9930) [] [] [2019-09-18 19:00:24] name.CRITICAL: Request Failed: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Kein gültiges Sicherheitsprofil. (9930) [] []

Also wurde der Fehler in einem der changes in 0c41d10d3d3a79bd8478baca2d03be16bab4a538 eingeführt.

Bin grad mal am drüber schauen, woran das genau in dem commit liegt.

[na-oma]

Es wurde nur

protected function getUsedPinTanMechanism($dialog) {
    if ($this->tanMechanism !== null AND in_array($this->tanMechanism, $dialog->getSupportedPinTanMechanisms()))
        return [$this->tanMechanism];

    return $dialog->getSupportedPinTanMechanisms();
}

in

protected function getUsedPinTanMechanism($dialog) {
    $mechs = array_keys($dialog->getSupportedPinTanMechanisms());
    if ($this->tanMechanism !== null && in_array($this->tanMechanism, $mechs)) {
        return [$this->tanMechanism];
    }
    return $mechs;
}

geändert, weil getSupportedPinTanMechanisms eigentlich ein assoziatives Array liefert/liefern sollte?

Allerdings liefert $dialog->getSupportedPinTanMechanisms() in getUsedPinTanMechanism (einfach mal var_dumpen) kein assoziatives array wie bei $fints->getVariables():

/var/www/html/tmp/sventest.php:2735:
object(stdClass)[38]
  public 'tanModes' => 
    array (size=7)
      910 => string 'chipTAN manuell' (length=15)
      911 => string 'chipTAN optisch' (length=15)
      912 => string 'chipTAN-USB' (length=11)
      913 => string 'chipTAN-QR' (length=10)
      920 => string 'smsTAN' (length=6)
      921 => string 'pushTAN' (length=7)
      900 => string 'iTAN' (length=4)

sondern ein flaches Array.

array (size=7)
  0 => int 910
  1 => int 911
  2 => int 912
  3 => int 913
  4 => int 920
  5 => int 921
  6 => int 900

Was davon ist korrekt? Oder tritt das nur bei der Spaßkasse so auf?

[roben]

Bist du denn auf dem aktuellsten Stand? Das ist eigentlich schon gefixt. Mir ist da bei meinem PR leider die Dialog.php durch die Lappen gegangen, in der getSupportedPinTanMechanisms() umgebaut wurde.

[na-oma]

Bin jetzt davon überzeugt, dass es tatsächlich nicht aufgrund deines inkompletten PR 0c41d10d3d3a79bd8478baca2d03be16bab4a538 kaputt ist, denn wenn ich diesen nutze und return array(920); in getUsedPinTanMechanism hart reinschreibe, geht es wieder. Also beschuldige ich jetzt den Merge direkt danach: bf0f7adc30db2aa8b66b13bc412fcc0c49863afc Dieser fixt zwar getUsedPinTanMechanismbzw. getSupportedPinTanMechanisms, aber irgendwas macht er auch kaputt.

Testcode:

        $fints = new FinTs(...);
        //$fints->setTANMechanism(920, 'Script');//habe mit und ohne getestet.
        $accounts = $fints->getSEPAAccounts();

commit	ohne setTANMechanism	mit setTANMechanism(920, 'Script');
25d05350ad56b20ddc2c1435126561f6f91141fa	:white_check_mark:	:white_check_mark:
0c41d10d3d3a79bd8478baca2d03be16bab4a538	:x:	:x:
0c41d10d3d3a79bd8478baca2d03be16bab4a538 hardcoded getUsedPinTanMechanism	:white_check_mark:	:white_check_mark:
bf0f7adc30db2aa8b66b13bc412fcc0c49863afc	:x:	:x:
bf0f7adc30db2aa8b66b13bc412fcc0c49863afc hardcoded getUsedPinTanMechanism	:x:	:x:
current: 6af28afb7a2702ad5b9563e40322e541ef04b39d	:x: "PIN/TAN-Verfahren widerspricht dem Legitimationsvertrag."	:x: "Kein gültiges Sicherheitsprofil."
current: 6af28afb7a2702ad5b9563e40322e541ef04b39d hardcoded getUsedPinTanMechanism	:x: "Kein gültiges Sicherheitsprofil."	:x: "Kein gültiges Sicherheitsprofil."

Also auch in der aktuellen version funzt es nicht! Ich werde jetzt mal bf0f7adc30db2aa8b66b13bc412fcc0c49863afc anschauen und evtl. mal die generierten Messages diffen...sind aber viele changes...

[na-oma]

Heureka, ich habe eine Lösung gefunden.

        $fints = new FinTs(...);
        $fints->setTANMechanism(920, 'Script');
        $accounts = $fints->getSEPAAccounts();

Wenn man getSEPAAccounts aufruft, wird irgendwann initDialog aufgerufen. Dies erzeugt eine Message, die alle $supportedTanMechanisms als $optionserhält. Das sind bei mir:

    array (size=7)
      910 => string 'chipTAN manuell' (length=15)
      911 => string 'chipTAN optisch' (length=15)
      912 => string 'chipTAN-USB' (length=11)
      913 => string 'chipTAN-QR' (length=10)
      920 => string 'smsTAN' (length=6)
      921 => string 'pushTAN' (length=7)
      900 => string 'iTAN' (length=4)

Message nutzt davon den ersten, also 910 per $this->securityFunction = $this->options[static::OPT_PINTAN_MECH][0];. initDialog geht dann erstmal korrekt durch.

Beim darauffolgenden Senden der getSEPAAccounts Nachricht nach "(SEPA accounts) initialize" wird allerdings wieder $this->getUsedPinTanMechanism($dialog) aufgerufen, was wiederum dazu führt, dass diese Message 920 als OPT_PINTAN_MECH nutzt.

Die Sparkasse kommt scheinbar nicht mit einem mit 910 initialisierte Dialog bzw. mit einer darauffolgenden getSEPAAccounts-Nachricht mit 920 als PinTan Mechanismus zurecht.

Lösung: initDialog bekommt genau wie syncDialog ebenfalls den Parameter $tanMechanism:

public function initDialog($tanMechanism = null, $tanMediaName = null)

Oder ist es absicht, dass in initDialog keinen $tanMechanism hat?

[nemiah]

@roben bitte sag bei Gelegenheit was dazu, ich denke, du hast die Änderung mit dem $tanMediaName eingebaut.

[roben]

Sorry, bei mir gehts gerade drunter und drüber. Dieser Mechanismus, dass aus der Liste irgendwas ausgewählt wird, ist mir auch schon aufgefallen, aber den hatte ich erstmal ignoriert. Mit der neuen $tanMediaName sollte das aber nicht zusammen hängen. Ich muss mir das aber noch mal in Ruhe anschauen, komme aber wohl erst nächste Woche dazu. Grundsätzlich sollte aber der $tanMechanism genommen werden, der übergeben wird.

array(AbstractMessage::OPT_PINTAN_MECH => array_keys($this->supportedTanMechanisms)) sieht aber wirklich so aus, als sollte das nicht so sein. Vermutlich ist der Code dazu auch noch recht alt.

initDialog bekommt genau wie syncDialog ebenfalls den Parameter $tanMechanism:

Hört sich jedenfalls gut an. Mach doch bitte mal einen PR. @nemiah vielleicht können wir sowas zum Testen erstmal in einen experimental-Branch mergen?

[nemiah]

Die Idee mit dem extra branch hatte ich auch schon. @na-oma bitte schick einen PR an https://github.com/nemiah/phpFinTS/tree/exp :wink:

[na-oma]

PR ist da, hoffe das passt alles, mach selten welche. Hab kaum Plan von dem Code, werde das jetzt über das WE testen, bisher gehts bei Sparkasse Dresden und Volksbank Dresden. (Volksbank ging vorher schon...) Nutze aber nur getSEPAAccounts und getStatementOfAccount/getStatements/getTransactions/....

@djm03 Wär cool, wenn du mit testest :)

Die getUsedPinTanMechanismist tatsächlich etwas komisch, macht offensichtlich nicht das was sie soll, wenn sie 920 bei einem mit 920 initialisierten Dialog zurückgibt. Evtl. in die Dialogklasse?

Danke auf jedem Fall für eure Arbeit! sonst wären wir hier aufgeschmissen! 4 Std. Fehlersuche, 4 Zeilen fix, alles wie immer ;)

[nemiah]

Denk dir nix, der meiste Code ist auch nicht von mir und irgendwie funktionierts :wink:

Danke für den PR, bei mir sieht es gut aus. Ich denke, die getUsedPinTanMechanism() wird überflüssig, weil inzwischen eigentlich überall das TAN-Verfahren fest übergeben wird.

4 Std. Fehlersuche, 4 Zeilen fix, alles wie immer ;)

Das sind die besten Fixes :stuck_out_tongue_winking_eye:

[djm03]

Mir war nicht ganz klar wie ich die Version runterladen kann. Hab dann unter:

https://github.com/nemiah/phpFinTS/tree/exp

dort per Clone or download die zip geladen. Damit funktioniert es wieder. Super :)

Ansonsten bin ich mal meine Änderungen durchgegangen, welche ich im Laufe der Zeit eingebaut hatte. Dabei ist mir aufgefallen, dass in MT940.php Zeile 135 weiterhin steht:

$year = substr($transaction, 2, 2) < substr($transaction, 6, 2) ? --$year : $year;

Meiner Meinung nach wird das $bookingDate so nicht korrekt ermittelt (deswegen bei mir auskommentiert), weil es bei den Daten nicht funktioniert: 61:1906290701 = 01.07.18?

Den folgenden Code mit 12 und 01 bzw. 01 und 12 zum Jahreswechsel hatte ich auch schon ergänzt. Nur Zeile 135 passt irgendwie nicht.

Oder übersehe ich etwas?

Weiterhin fände ich es gut, wenn rawData je Buchung abfragen könnte (würde ich gern mit zu jeder Buchung speichern).

[nemiah]

@roben Funktioniert bei dir der exp-Branch auch? Weil dann würde ich den PR einfach mal in den master rüberholen. Wenn ich rausfinde, wie das geht :wink:

Ich hatte seither kein Problem mehr mit dem Buchungsdatum, keine Ahnung, wie man das korrekt parst.

Schick mir bitte einen PR mit dem rawData, das ändert ja nix an der Funktionalität.

[roben]

Hört sich gut an, ich kann es aber erst am Montag testen. Du kannst den Branch mit git merge exp in deinen master übenehmen.

[djm03]

@nemiah 61:1906290701 (bzw: 61:1812310102 61:1901011228) 19 = Jahr 0629 = 29.06. (valutaDate) 0701 = 01.07. (bookingDate)

$year = substr($transaction, 0, 2); $valutaDate = $this->getDate($year . substr($transaction, 2, 4));

$bookingDate = substr($transaction, 6, 4);

// if valuta date is earlier than booking date, then it must be in the new year. $year = substr($transaction, 2, 2) < substr($transaction, 6, 2) ? --$year : $year;

if (substr($transaction, 2, 2) == '12' && substr($transaction, 6, 2) == '01') { $year++; } elseif (substr($transaction, 2, 2) == '01' && substr($transaction, 6, 2) == '12') { $year--; } $bookingDate = $this->getDate($year . $bookingDate);

Wenn ich richtig schaue, wird aus:

61:1906290701 29.06.19 und 01.07.18 = falsch

61:1812310102 31.12.18 und 02.01.19 = richtig

61:1901011228 01.01.19 und 28.12.17 = falsch

ohne

// if valuta date is earlier than booking date, then it must be in the new year. $year = substr($transaction, 2, 2) < substr($transaction, 6, 2) ? --$year : $year;

würde es passen

[nemiah]

Ok, ich bitte um einen PR :wink:

[na-oma]

War letzte Woche leider krank, aber schön dass es funktioniert hat^^

@djm03 Hab mal eine Neue Issue für das Datum aufgemacht, damit alles seine Ordnung hat: #62