Tom Feller: htaccess - keine Login-Daten im SERVER-Array

Beitrag lesen

Hallo Sven,

Zwei mögliche Szenarien sind denkbar:

  1. Der Browser merkt sich ggf., ob für die Abfrage einer Ressource schon mal ein Passwort verlangt wurde, und sendet bei einem erneuten Request einfach die gespeicherten Anmeldedaten schon mit - oder eben nicht.

  2. Der Browser versucht immer, ohne Anmeldedaten Zugriff zu erlangen, und nur beim scheiternden Versuch (Status 401) versucht er, bereits eingegebene Anmeldedaten, die schon mal bei identischem REALM angegeben wurden, mitzusenden. Schlägt auch das fehl, wird erneut das Passwortfenster angezeigt.

Dieses Verhalten ist "normal". Es gibt bei HTTP-Authentifizierung kein "eingeloggt", was man auf andere Seiten mitschleifen könnte, sondern es gilt nur die jeweilige Ressource, und dafür der erlaubte oder verweigerte Zugriff qua definitionem der .htaccess.

das erklärt das Verhalten - und wahrscheinlich kann man da auch nichts gegen machen, da das Ganze ja anscheinend der Browser entscheidet. Dann muss ich also umdenken...

Da .htaccess am einfachsten arbeitet, wenn es verzeichnisorientiert eingesetzt wird, solltest du deine URLs für öffentlichen und authentifizierten Zugang ebenfalls separiert verwalten. Dann wird jeglicher Zugriff auf das authentifizierte Verzeichnis mit Passwort und Username abgewickelt, und du hast auf die Information REMOTE_USER Zugriff.

Und so habe ich es jetzt auch gemacht. Ich wollte mir das eigentlich ersparen, da ich jetzt zweimal die gleichen Dateien auf dem Server habe und ich auch doppelten Pflegeaufwand habe, aber es führt wohl kein Weg daran vorbei.

Abgesehen davon ist ein Verzeichnis, in dem NICHT mit .htaccess der Zugang kontrolliert wird, grundsätzlich unkontrollierter Zugriff von außen möglich. Lediglich die Skripte, die die Authentifizierung prüfen, würden ggf. den Zugriff ablehnen. Es ist von daher taktisch unklug, auf .htaccess zu verzichten.

Ja, das wollte ich auch nicht...

Du Sven, weißt Du, wie sicher der htaccess-Login ist? Ich habe irgendwo was gelesen von DES-Verschlüsselung der crypt-Funktion, und die hat wohl nur 56 bit. Und trotzt den Standardmäßigem Salt von 2 Ziffern bin ich mir nicht sicher, ob die so generierten Passwörter einem Brut-Force standhalten. Weißt Du was darüber? Oder auch Abhilfe? Denn da ich die Daten des Login-Fenster ja nicht selber Abfrage und überprüfe, sondern das automatisch passiert kann ich ja auch die Verschlüsselungsmethode nicht ändern...
Da irgendeine Idee?

Habe das Ganze jetzt auf jeden Fall aufgeteilt und es läuft so wie gewollt! Habe da wohl etwas zu kompliziert gedacht / bzw. der heutigen IT-Landschaft zu viel zugetraut... ;-)

0 42

htaccess - keine Login-Daten im SERVER-Array

Tom Feller
  • php
  1. 0
    Matze
    1. 0
      Tom Feller
      1. 0
        Matze
        1. 0
          Tom
      2. 0
        Tom
        1. 0
          Tom Feller
          1. 0
            Tom
            1. 0
              Tom Feller
              1. 0

                Zum Testen

                Tom
                1. 0
                  Tom Feller
                  1. 0
                    Tom
                  2. 0
                    Tom
                    1. 0

                      Zum Testen, Version für CGI

                      Tom
            2. 0
              Tom
              1. 0
                Tom Feller
  2. 0
    Sven Rautenberg
    1. 0
      Tom
      1. 0
        Sven Rautenberg
    2. 0
      Tom Feller
      1. 0

        Bitte noch den Test durchführen

        Tom
        1. 0
          Tom Feller
          1. 0

            Und noch eine Idee für die Fehlerquelle

            Tom
          2. 0

            Erste Fehlerquelle gefunden

            Tom
            1. 0
              Tom Feller
              1. 0

                Kommt $_SERVER['HTTP_CGI_AUTHORIZATION'] an?

                Tom
                1. 0
                  Tom Feller
                  1. 0
                    Tom Feller
                    1. 0
                      Tom
                      1. 0
                        Tom Feller
                        1. 0

                          Rien ne vas plus avec cet server

                          Tom
                          1. 0
                            Tom Feller
                            1. 0
                              Tom
                              1. 0
                                Tom Feller
                  2. 0
                    Tom
      2. 1
        Sven Rautenberg
        1. 0
          Tom Feller
          1. 1
            Sven Rautenberg
            1. 0
              Tom Feller
              1. 0

                Atombomben und Atomkraftwerke ;-)

                Christian Seiler
                • menschelei
            2. 0

              Crypt auf MD5-Basis

              Dennis
              • programmiertechnik
              1. 0
                Tom Feller