Frontenduser mit Umlauten

[theodorH]

Werden im Backend Frontenduser mit Umlauten (z.B. Häß) angelegt, so können diese sich nicht anmelden. Wird bei der Frontendanmeldung der Name "ohne Umlaute" geschrieben (z.B. Has), so ist die Anmeldung möglich, obwohl im Backend (Häß) steht. Die Datenbank ist auf UTF-8 eingestellt, in der config.ini auch. Wo muss noch etwas geändert werden, dass Frontenduser mit ihrem normalen Namen sich anmelden können? (In der Version 4.8 war dies möglich.)

[rethus]

Schau mal in die Frontend-Page. In welchem charset wird die ausgeliefert?
Du du hier die Eingabe tätigst, sollte die auch utf-8 sein.

[theodorH]

Frontend ist auch auf UTF-8 eingestellt.

Ich habe zwei Standardinstallationen mit Beispielmandant auf unterschiedlichen VMs installiert (PHP 5.6 /7). Hier lässt sich der BUG leicht nachvollziehen. Im Backend wird der Frontenduser mit Umlaut (ä) angelegt, in der Datenbank wird der Umlaut angezeigt (UTF-8), die Anmeldung des Frontendusers gelingt nur, wenn der Umlaut (ä) gegen ein (a) ausgetauscht wird.

[rethus]

Mhh, hört sich nach einem Bug an, sollte aber zuvor genau geprüft werden, ehe es in den BugTracker eingetragen wird.

Gehe doch bitte mal den Weg des logins mit Xdebug, oder mit Kontrollausgaben nach.
Dann siehst du an welcher Stelle das Umlaut-Problem auftritt.

[theodorH]

Das Problem tritt schon im Backend auf. Legt man einen Benutzer mit Umlaut (z.B. Männer) an und versucht diesen umbennen in "Manner", so erfolgt ein Error-> Benutzer bereits vorhanden. Hier wird der Umlaut "ä" und der Buchstabe "a" gleichgesetzt.

[homtata]

Dass Contenido hier ä und a gleichsetzt, kann ich in meinen Installationen so nicht nachvollziehen, das wäre auch sehr seltsam. WAS ich allerdings sagen kann: in den meisten meiner Neuinstallationen ist die Datenbankkollation zwar utf-8, aber eben nicht immer konsequent auch die Tabellen- und Spaltenkollationen, die sind oft noch latin1_german2_ci. Und DANN schlägt das Umlautproblem gnadenlos zu. Beim ersten Abspeichern des Usernamens landet dann statt "nämlich" die Variante "nämlich" in der DB, und beim erneuten Abspeichern wird ggf. sogar das & NOCHMAL umgeschrieben. Auf jeden Fall wird dann die UTF-8-Eingabe des Formulars mit dem falschen DB-Eintrag verglichen, der nicht mehr stimmen kann.
Frage daher: sind bei dir auch WIRKLICH sowohl die Tabellenoptionen jeder Tabelle als auch die Spaltenkollationen auf utf-8? Wenn nein, kann das eigentlich nur schiefgehen.
In der 4.8 hats wahrscheinlich geklappt, weil ALLES html-codiert wurde, DB und Formular-Eintrag - dann stimmte der Abgleich.