Rentieropa1: .htacces Umlaute im Benutzernamen

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?

  1. 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?

    • Welches OS?
    • Welche Codierung im Dateisystem?
    • Wie wirde gemounted?
    • Welcher Webserver?
    • Welche Codierung für die Webseiten?

    Wenn alle dieselbe Codierung benutzen, klappt es auch mit Umlauten.
    Sonst wird es spannend...

    Glück Auf
    Tom vom Berg

    --
    Es gibt nichts Gutes, außer man tut es!
    Das Leben selbst ist der Sinn.
    1. OS ist Windows10

      1. 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

        --
        Es gibt nichts Gutes, außer man tut es!
        Das Leben selbst ist der Sinn.
        1. 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:

          • Der TO verwendet HTTP-AUTH als Passwortschutz für seine Website
          • Einige Benutzernamen enthalten Umlaute
          • Das war bis vor kurzem unproblematisch, nun werden diese Benutzernamen aber nicht mehr korrekt erkannt

          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

          --
          Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
          1. 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.

            Meine These:

            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

            --
            Es gibt nichts Gutes, außer man tut es!
            Das Leben selbst ist der Sinn.
            1. 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

              --
              Ich stamme aus Ironien, einem Land am sarkastischen Ozean.
              1. 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

                --
                Es gibt nichts Gutes, außer man tut es!
                Das Leben selbst ist der Sinn.
        2. 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

        3. Leider gibt es keine Fehlermeldung. Das .htaccess-Abfrageformular poppt nur immer wieder auf. Ich frage mal beim Provider nach.

    2. 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

      1. 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

        --
        Es gibt nichts Gutes, außer man tut es!
        Das Leben selbst ist der Sinn.
        1. 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

          --
          Ich bin Ingenieur. Um uns allen Zeit zu sparen, gehen Sie bitte davon aus, dass ich recht habe.
          1. 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

            --
            Es gibt nichts Gutes, außer man tut es!
            Das Leben selbst ist der Sinn.