nicht angemeldet
TS
TS
Der Martin
TS
Der Martin
TS
Felix Riesterer
MudGuard
TS
Der Martin
TS
Hallo zusammen. Ich hoffe,es kann mir jemand helfen. Jahrelang funktionierte mein Passwortschutz per .htaccess anstandslos. Nun werden die Benutzer mit Umlaut im Namen plötzlich abgelehnt. Was hat sich geändert? Wie kann ich abhelfen?
Hello,
Hallo zusammen. Ich hoffe,es kann mir jemand helfen. Jahrelang funktionierte mein Passwortschutz per .htaccess anstandslos. Nun werden die Benutzer mit Umlaut im Namen plötzlich abgelehnt. Was hat sich geändert? Wie kann ich abhelfen?
Wenn alle dieselbe Codierung benutzen, klappt es auch mit Umlauten.
Sonst wird es spannend...
Glück Auf
Tom vom Berg
OS ist Windows10
Hello,
OS ist Windows10
Das ist aber noch nicht einmal die halbe benötigte Information.
Windows wird wohl CP 1252 Westeuropäisch benutzen.
Welche Codierung benutzt der Webserver für die Webseiten? Vermutlich UTF-8. Mit ISO-8859-1 würde es vermutlich (meistens) klappen. Die ist "sehr ähnlich" der Win1252-WEu.
Was hat sich denn gegenüber früher geändert am System? Woher kommt die Fehlermeldung?
Glück Auf
Tom vom Berg
Hallo,
OS ist Windows10
Das ist aber noch nicht einmal die halbe benötigte Information.
gehen wir mal davon aus, dass der TO technisch nicht versiert genug ist, um überhaupt alles zu verstehen, was du wissen willst.
Fassen wir mal zusammen:
Windows wird wohl CP 1252 Westeuropäisch benutzen.
Ja, aber der unter Windows laufende Browser (hier wäre interessant, welcher das ist) folgt u.U. eigenen Regeln oder denen der IETF. Interessant finde ich, dass der für HTTP-AUTH zuständige RFC 7235 kein Wort über die Zeichencodierung verliert. Das scheint also undefiniert zu sein.
Bei der Suche fand ich auch einen Artikel im MDN. Dort heißt es beiläufig:
Browsers use utf-8 encoding for usernames and passwords. Firefox used to use ISO-8859-1, but changed over to utf-8 for parity with other browsers, and to avoid potential problems as described in bug 1419658.
Okay, es wird also einfach behauptet, dass UTF-8 verwendet wird, und dass Firefox bis vor Kurzem (der Artikel ist von Ende Oktober 2019) noch ISO-8859-1 stattdessen verwendet hat. Leider steht nicht konkret dabei, in welcher Version diese Änderung eingeführt wurde. Aber genau diese Änderung könnte der Grund sein, warum es beim Rentieropa bis vor kurzem funktioniert hat und jetzt auf einmal nicht mehr (vorausgesetzt, er verwendet ISO-8859-1 oder eine ähnliche Codierung, und als Browser den Firefox).
Ergo: Die zu verwnedende Zeichencodierung für HTTP-AUTH ist anscheinend nicht normativ festgelegt. UTF-8 ist vermutlich eine Lösung, die in den meisten Fällen Erfolg verspricht; sicherer ist es aber, Nicht-ASCII-Zeichen im Benutzernamen und im Kennwort zu vermeiden
Ciao,
Martin
Hello,
Windows wird wohl CP 1252 Westeuropäisch benutzen.
Ja, aber der unter Windows laufende Browser (hier wäre interessant, welcher das ist) folgt u.U. eigenen Regeln oder denen der IETF. Interessant finde ich, dass der für HTTP-AUTH zuständige RFC 7235 kein Wort über die Zeichencodierung verliert. Das scheint also undefiniert zu sein.
Der Browser ist an dieser Stelle uninteressant. Hier betrachten wir das Dateisystem und den Webserver. Der Browser sendet und empfängt mit der Einstellung des Webservers.
Aber es wurden vermutlich Daten übernommen.
Irgendetwas im System hat sich geändert und die Daten wurden nicht passend migriert.
Oder die (neuen) Daten (User und Passworte) wurden am Webserver vorbei nicht mit dem Browser und einem Skript erfasst, sondern mit einem Editor des Betriebssystems. Der codiert (Umlaute) dann natürlich mit Win1252-WEu, während der Browser die Umlaute (heutzutage) mit UTF-8 codiert.
Man müsste also die User- und Passwortverwaltung mit dem Browser und einem passenden Webserverskript dafür durchführen, oder aber z. B. einen Editor benutzen am Server-Host, der UTF-8 speichert.
Das dickste Problem tritt erst auf, wenn man früher erfasste Dateien nicht sauber migriert hat und nun mit einer anderen Codierung darin herumschreibt.
Glück Auf
Tom vom Berg
Hallo Tom,
Windows wird wohl CP 1252 Westeuropäisch benutzen.
Ja, aber der unter Windows laufende Browser (hier wäre interessant, welcher das ist) folgt u.U. eigenen Regeln oder denen der IETF. Interessant finde ich, dass der für HTTP-AUTH zuständige RFC 7235 kein Wort über die Zeichencodierung verliert. Das scheint also undefiniert zu sein.
Der Browser ist an dieser Stelle uninteressant. Hier betrachten wir das Dateisystem und den Webserver. Der Browser sendet und empfängt mit der Einstellung des Webservers.
das hatte ich auch erst vermutet. Der MDN-Artikel, den ich verlinkt habe, behauptet aber etwas anderes. Abgesehen davon: HTTP-AUTH funktioniert ja auch, ohne dass vorher irgendeine Ressource vom Server angefordert wurde (z.B. per Bookmark und im Browser gespeicherten Anmeldedaten oder sogar per http://user:pass@example.net/ in der URL-Zeile). In diesem Fall fehlen dem Browser sämtliche Angaben zum erwarteten Encoding.
Meine These:
Irgendetwas im System hat sich geändert und die Daten wurden nicht passend migriert.
Auch möglich.
Oder die (neuen) Daten (User und Passworte) wurden am Webserver vorbei nicht mit dem Browser und einem Skripg erfasst, sondern mit einem Editor des Betriebssystems. Der codiert (Umlaute) dann natürlich mit Win1252-WEu, während der Browser did Umlaute (heutzutage) mit UTF-8 codiert.
Dann würde Rentieropa aber wissen, dass er etwas geändert hat.
Das dickste Problem tritt erst auf, wenn man früher erfasste Dateien nicht sauber migriert hat und nun mit einer anderen Codierung darin herumschreibt.
Aber für weitere Mutmaßungen haben wir im Moment nicht genug Munition (lies: Information).
Ciao,
Martin
Hello,
user:password@example.org macht man aber nicht [tm]
Der vollständige Dialog enthält eine Challenge mit Status 401.
Der Monolog des Browsers (Wiederbesuch der Seite) sollte dann schon die passend codierten Credentials gespeichert haben. Außerdem war hierfür schon immer utf-8 vereinbart. Nur Firefox hat sich nicht daran gehalten. siehe Beschreibung und Bugreport
Glück Auf
Tom vom Berg
Lieber TS,
OS ist Windows10
Das ist aber noch nicht einmal die halbe benötigte Information.
richtig, Du wirst wohl davon ausgehen müssen, dass mit "Windows 10" das OS des Clients mit dem Browser (welcher?) gemeint ist. Welches OS auf dem Server läuft (wahrscheinlich ein Linux), ist unklar.
Liebe Grüße
Felix Riesterer
Leider gibt es keine Fehlermeldung. Das .htaccess-Abfrageformular poppt nur immer wieder auf. Ich frage mal beim Provider nach.
Hi,
- Welche Codierung für die Webseiten?
Was soll die Codierung einer Webseite mit einem Codierungsproblem der Basic Authentification zu tun haben?
Diese findet im HTTP-Header statt, und hat nichts mit einer Webseite zu tun - die funktioniert ja auch für Dateien, die keine Zeichencodierung haben (Binärdateien).
cu,
Andreas a/k/a MudGuard
Hello,
Hi,
- Welche Codierung für die Webseiten?
Was soll die Codierung einer Webseite mit einem Codierungsproblem der Basic Authentification zu tun haben?
Diese findet im HTTP-Header statt, und hat nichts mit einer Webseite zu tun - die funktioniert ja auch für Dateien, die keine Zeichencodierung haben (Binärdateien).
Es kommt darauf an, wie User und Passwort amgelegt werden.
Wenn dies mittely Webdialog (Client- Server) geschieht, müssen die Codierungen beachtet werden.
Wenn ein älterer Firefox benutzt wird, ist die Codierung für das 401-Popup versehentlich iso-8859-1, anstelle der für Badic Auth vorschriebenen utf-8.
Meiner Erinnerung nach war dies aber mittels Content-Type/Charset-Angabe im Alternativtext des 401-Dialoges änderbar.
Glück Auf
Tom vom Berg
Hallo Tom,
Wenn ein älterer Firefox benutzt wird, ist die Codierung für das 401-Popup versehentlich iso-8859-1, anstelle der für Badic Auth vorschriebenen utf-8.
woher nimmst du die Sicherheit, dass UTF-8 vorgeschrieben sei? Dass Firefox bis vor einiger Zeit ISO-8859-1 verwendet hat und dann auch zu UTF-8 umgeschwenkt ist, um es den anderen Browsern gleichzutun, habe ich ja schon erwähnt.
Was mir fehlt, ist eine Aussage, welche Codierung denn verwendest werden soll oder sogar muss. Ich habe nämlich nichts Verbindliches gefunden.
Meiner Erinnerung nach war dies aber mittels Content-Type/Charset-Angabe im Alternativtext des 401-Dialoges änderbar.
Und ich widerspreche nochmal: HTTP(S) ist ein zustandsloses Protokoll. Es wäre also nicht zulässig oder zumindest nicht zwingend verbindlich, Informationen aus einem vorhergehenden Request/Response-Zyklus dafür heranzuziehen.
Schönen Abend noch,
Martin
Hello,
Wenn ein älterer Firefox benutzt wird, ist die Codierung für das 401-Popup versehentlich iso-8859-1, anstelle der für Badic Auth vorschriebenen utf-8.
woher nimmst du die Sicherheit, dass UTF-8 vorgeschrieben sei? Dass Firefox bis vor einiger Zeit ISO-8859-1 verwendet hat und dann auch zu UTF-8 umgeschwenkt ist, um es den anderen Browsern gleichzutun, habe ich ja schon erwähnt.
Was mir fehlt, ist eine Aussage, welche Codierung denn verwendest werden soll oder sogar muss. Ich habe nämlich nichts Verbindliches gefunden.
Hab ich mal irgendwo nachgelesen, wo es verbindlich zu sein schien, als ich vor langer Zeit mal meine Auth-Module gebastelt habe. Den Hinweis bekam ich damals von Sven Rautenberg. Muss sich also theoretisch hier im Forumsarchiv befinden (ca. ab 2001).
Zuhause kann ich ab dem 04.01. gerne nachschauen, ob ich mir eine Notiz dazu gemacht habe. Ich finde jetzt leider nur diese Story. Die RFC kam erst später.
Meiner Erinnerung nach war dies aber mittels Content-Type/Charset-Angabe im Alternativtext des 401-Dialoges änderbar.
Und ich widerspreche nochmal: HTTP(S) ist ein zustandsloses Protokoll. Es wäre also nicht zulässig oder zumindest nicht zwingend verbindlich, Informationen aus einem vorhergehenden Request/Response-Zyklus dafür heranzuziehen.
Muss ja auch gar nicht. Der 401-Roundturn ist ja ein eigener, der beim Browser bei Bedarf in einem "Modal-Popup" des Dokumentenfensters angezeigt wird und dieses bei Misserfolg oder Abbruch überschreibt. In diesem Überschreib-Alternativdokument kann man eine Charset-Angabe unterbringen.
Moin und guten Rutsch Tom von der See
