Nach Umstellung des Passworts ist die Fehlermeldung verwirrend

[dh3wr]

Wenn man sein eigenes Passwort ändert, wir nach Druck auf "Save" verzucht, die Userliste erneut zu laden. Dies aber wohl mit der alten Identifizierung, welche dann sagt "API-Server not found". Könnte man bei der Änderung seines eigenen Passworts automatisch "ausgeloggt" werden, so dass man zwangsweise sein neues Passwort eingeben muss?

[menzerath]

Wenn man sein eigenes Passwort ändert, werden die im Browser gespeicherten Authentifizierungsdaten automatisch aktualisiert. Daher sollte das Laden der Userliste anschließend auch funktionieren (gerade getestet).

[dh3wr]

Ging bei einem User heute morgen nicht. Soll ich mal nach dem Browser fragen?

[menzerath]

Gerne. Browser inkl. Version und Add-Ons wären interessant.

[dh3wr]

[menzerath]

Mit der aktuellen Version von Edge (40.15063.0.0) kann ich das Problem auch nicht nachvollziehen...

[menzerath]

Gibt es hier Neuigkeiten?

[menzerath]

Wenn es Neuigkeiten gibt, kannst du das hier gerne wieder aufmachen

[dh3wr]

Wir haben noch so einen Fall. Ich habe die Browser-Infos angefragt.

[dh3wr]

Es scheint daran zu liegen, dass die Menschen Zeichen außerhalb von a-z, A-Z und 0-9 verwenden. Jedenfalls ist das gerade aufgefallen, dass die Änderung nach Beispiel1234 geht, ein Passowrt mit ! und : aber nicht. Wie sieht es mit Sonderzeichen aus beim Passwort? Wo kann da etwas schief gehen? @MarvinMenzerath @Taronyu

[menzerath]

Das Problem wird im verwendeten Doppelpunkt liegen. Das Format der Authentifizierungsdaten ist ein Base64 kodierter String nach dem <username>:<password> Schema. Anscheinend prüfen aber weder das Web-Interface, noch der Core ob das Passwort nur aus A-Z, a-z und 0-9 besteht...

[dh3wr]

Hmm, am Besten könnte man ja alle Unicode-Zeichen unterstützen. Laut https://de.wikipedia.org/wiki/Base64 sollte doch in Base64 gar kein Doppelpunkt als Zeichen vorkommen, oder?

[menzerath]

Der Base64 kodierte String enthält auch keinen Doppelpunkt, der dekodierte String allerdings in diesem Fehlerfall zwei oder mehr.

Ich vermute, dass das Problem beim Core liegt, der an irgendeiner Stelle im Authentifizierungsprozess am Doppelpunkt splittet und damit nicht das ganze Passwort erwischt. Das Web-Frontend reicht den Authentifizierungsstring jedenfalls bloß in dem bekannten Format durch und behandelt ihn nicht weiter. Als Workaround habe ich 335dd07 implementiert, der einfach keine Doppelpunkte als Eingabe zulässt.

[Taronyu]

Bei Basic Auth wird Username und Passwort durch ein ":" zusammengepackt. Im Core wird dann in der Tat der String per Tokenizer mit Doppelpunkt als Trenner zerlegt. Das funktioniert also schon mal nicht, wenn Username oder Passwort Doppelpunkte enthalten. Ich habe das jetzt mal so umgebaut, dass alles bis zum ersten Doppelpunkt der Username und alles weitere das Passwort ist.

[dh3wr]

Bei Base64 wird doch ein Doppelpunkt ersetzt. Ist man nicht mit der Variante (Base64:Base64) immer auf der sicheren Seite für Basic Auth? Also erst Base64 und dann mit Dopplepunkt zusammenbauen und zum dekodieren entsprechend anders herum.

[Taronyu]

Hier wäre nur das Problem, dass man das Passwort dann immer vorab in Base64 kodieren muss. Ein Anmelden über den Browser, wget oder SoapUI braucht dann immer das Base64 Passwort, das Klartextpasswort funktioniert dann nicht mehr. Solange der Benutzername keinen Doppelpunkt enthält (wird das geprüft?), dürfte das jetzt aber keine Probleme mehr machen.