Ich habe die PIN geändert und dabei alle von Fiducia erlaubten Zeichen benutzt (alphanumerisch + @ + Leerzeichen).

Online funktioniert das Einloggen damit auch, aber 4W scheint die PIN nicht korrekt zu übertragen.
Ich vermute mal, dass die Leerzeichen falsch interpretiert werden.

Nachdem ich die PIN un-sicherheitshalber wieder vereinfacht habe, funktioniert auch das Einloggen mit 4W wieder.

wie lang ist denn deine PIN?

Gruß
Raimund
/könnte in einigen Kulturkreisen eine ziemlich indiskrete Frage sein...

meine PIN ist die längste

(Maximallänge bei Fiducia = 20)

*grins* - da lässt sich auch vieles übertragen: Die Länge spielt kaum eine Rolle
Wichtig ist, was man damit macht
Weil nach mehrfacher Falscheingabe im PIN&TAN-Verfahren der Zugang bankseitig gesperrt wird, ist die Frage eher nicht die Länge, sondern wie die Verwendung aussieht (und wie es um die Sicherheit im Rechenzentrum bestellt ist).
Dein Verdacht mit den Leerzeichen lässt sich ja recht einfach verifizieren, hast du es schon ausprobiert?

Gruß
Raimund

nein, das mehrfache Entsperren wollte ich mir nicht antun.

Andreas kann leichter im Sourcecode nachprüfen, wo der Fehler liegt..

Hallo,

in HBCI sind generell keine führenden oder nachfolgenden Leerzeichen möglich. In der Mitte gehen Leerzeichen schon. Probleme bereitet bei den Volksbanken das "@"-Zeichen. Das liegt aber weniger an Banking 4W, als am HBCI-System der Volksbanken.

ok, dann schreibe ich das denen mal.
Kürzlich wurde doch tatsächlich das UTF-8/Latin Problem beseitigt - kurz nachdem ich das reklamiert hatte. Wird aber Zufall gewesen sein.

Ist es wirklich behoben worden? Wenn ja, woher weißt Du das?

Ich gehe eher davon aus, dass es die Sonderbehandlung ist, die Andreas genau dafür eingebaut hat...

naja, der Fehler tritt nicht mehr auf
Bei mir hing das damit zusammen, dass eine Kontobezeichnung einen Umlaut enthalten hat. Der Umlaut ist noch da, der Fehler nicht mehr..



echt? Wo hat er das geschrieben?
Ich dachte, das sei ein Fehler des Bank-Protokolls; der Fehler wird ja auch von der Bank geliefert.
Daran kann ein Banking Programm ja nichts ändern. Höchstens diese spezielle Meldung unterdrücken, was aber suboptimal wäre. Bestimmt hat er das nicht gemacht.

Ich habe einen Work-Around wie folgt eingebaut: Die Bytes der XML-Daten werden jetzt erst untersucht ob eine gültige UTF-8-Codierung vorliegt. Durch Redundanzen in der UTF-8-Codierung lässt sich das zum Glück ziemlich zuverlässig erkennen. Liegt keine gültige UTF-8-Codierung vor, dann nehme ich eine Latin-1-Codierung an. Es war dann noch etwas tricky, den XML-Parser aus .NET dazu zu bringen, die Angabe der Codierung im XML-Header zu ignorieren und statt dessen meine explizit gewählte Codierung zu verwenden. Aber es geht jetzt. Wieder ein paar Stunden für einen Work-Around für einen Fehler im Banksystem verschwendet. Von den vielen Supportanfragen und aus dem Fehler resultierenden schlecht gelaunten Benutzern ganz zu schweigen.

Hallo,

wenn ich so auf das Jahr 2013 zurückblicke, muss ich doch feststellen, dass sehr viele Wünsche der Anwender-Eingaben abgearbeitet wurden.
Dank der schnellen und wirksamen persönlichen Hilfe des "Chefs" gab es oft Stunden später bereits ein Update mit Fehlerbeseitigung.

Auch der obigen Fall zeigt, dass auch schwierige Fehler beseitigt werden, obwohl eigentlich die Zeit gar nicht so richtig vorhanden zu sein scheint.

Aus diesem Grunde sollten wir vor Weihnachten Ruhe einkehren lassen, damit Herr Selle auch noch etwas vom bevorstehendem Weihnachtsfest hat.

Wir könnten lieber selber mal Geschenke verteilen, auch wenn es nur in Form kleiner Danksagung geschieht.