getter: Komisches Verhalten von .htaccess

Hi zusammen,

Ich habe in mein Webprojekt einen Shop eingebaut. Nun habe ich dessen Adminbereich per .htaccess geschützt. Soweit funktioniert alles. Wenn man den Link direkt aufruft http://domain.ch/shop/admin/index.php erscheint das Eingabefenster und man kann den Benutzernamen und das Passwort eingeben. Ist es richtig, so wird der gesamte Zugriff auf den Admin-Ordner und dessen Unterordner freigegeben. Ja, soweit alles so wie es sein muss.
Nun habe ich aber für mein gesamtes Webprojekt einen Admin-Bereich eingerichtet. Von dort aus soll man mit einem Link in den Admin-Bereich des Shops kommen ohne Benutzernamen und Passwort eingeben zu müssen (da der Benutzer ja in meinem Admin-Bereich ist, gilt er als Berechtigt für den Zugriff). Dies habe ich mit PHP so realisiert: header("Location: http://benutzername:passwort@domain.ch/shop/admin/index.php"); .
Dies funktioniert auf den ersten Blick auch wie gewünscht. Der Zugriff wird gewährt. Ist man nun eingeloggt und will man eine Funktion in einem Unterverzeichnis von shop/admin/ nutzen, Bsp: shop/admin/artikel/edit.php, dann fragt der Browser nach dem Benutzernamen und Passwort für diesen Bereich.

Kann mir jemand sagen, weshalb sich das Ganze so verhält? Gibt es eine Möglichkeit dies zu umgehen?

Vielen Dank und Grüsse
Getter

  1. Hallo getter.

    Nun habe ich aber für mein gesamtes Webprojekt einen Admin-Bereich eingerichtet. Von dort aus soll man mit einem Link in den Admin-Bereich des Shops kommen ohne Benutzernamen und Passwort eingeben zu müssen (da der Benutzer ja in meinem Admin-Bereich ist, gilt er als Berechtigt für den Zugriff). Dies habe ich mit PHP so realisiert: header("Location: http://benutzername:passwort@domain.ch/shop/admin/index.php"); .
    Dies funktioniert auf den ersten Blick auch wie gewünscht. Der Zugriff wird gewährt. Ist man nun eingeloggt und will man eine Funktion in einem Unterverzeichnis von shop/admin/ nutzen, Bsp: shop/admin/artikel/edit.php, dann fragt der Browser nach dem Benutzernamen und Passwort für diesen Bereich.

    Kann mir jemand sagen, weshalb sich das Ganze so verhält?

    Eigentlich recht simpel: dein PHP-Script sendet an den Server die authentifizierenden Daten um Zugriff auf Ressourcen im geschützten Bereich zu erhalten. Der Client befolgt nur, wenn er so konfiguriert wurde, die Empfehlung, die Ressource „http://benutzername:passwort@domain.ch/shop/admin/index.php“ aufzurufen.

    Grundsätzlich müssen Clients sich in solch geschützten Bereichen beim Aufruf jeder einzelnen Ressource neu authentifizieren. Da dies recht schnell aber sehr nervig werden kann, speichern Clients die Daten nach einmaliger Eingabe zwischen. Da die Daten hier jedoch nicht mit Hilfe der clientseitigen Funktionalität (Dialogfenster) erfolgt ist, speichert er die Daten nicht zwischen.

    Gibt es eine Möglichkeit dies zu umgehen?

    Ich wüsste nicht, wie. Das einmalige clientseitige Absenden der Authentifizierungsdaten ist zwangsläufig erforderlich.

    Einen schönen Samstag noch.

    Gruß, Mathias

    --
    ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)
    debian/rules
    1. Hi,

      header("Location: http://benutzername:passwort@domain.ch/shop/admin/index.php");
      Eigentlich recht simpel:

      Offensichtlich nicht.

      dein PHP-Script sendet an den Server die authentifizierenden Daten um Zugriff auf Ressourcen im geschützten Bereich zu erhalten.

      Nö, PHP sendet in diesem Fall keine authentifizierenden Daten an irgendeinen Server.

      Es sendet eine inkorrekte URL, die Username/Paßwort enthält, an den _Client_.
      Was der Client dann damit macht, ist wie schon in meinem anderen Posting erwähnt, vom Client und dessen Konfiguration abhängig.

      cu,
      Andreas

      --
      Warum nennt sich Andreas hier MudGuard?
      Schreinerei Waechter
      O o ostern ...
      Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
      1. Hallo MudGuard.

        header("Location: http://benutzername:passwort@domain.ch/shop/admin/index.php");
        Eigentlich recht simpel:

        Offensichtlich nicht.

        dein PHP-Script sendet an den Server die authentifizierenden Daten um Zugriff auf Ressourcen im geschützten Bereich zu erhalten.

        Nö, PHP sendet in diesem Fall keine authentifizierenden Daten an irgendeinen Server.

        Es sendet eine inkorrekte URL, die Username/Paßwort enthält, an den _Client_.

        Was ich ja im folgenden in diesem Absatz auch korrekter so schrieb.

        Was der Client dann damit macht, ist wie schon in meinem anderen Posting erwähnt, vom Client und dessen Konfiguration abhängig.

        Dito.

        Einen schönen Samstag noch.

        Gruß, Mathias

        --
        ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)
        debian/rules
      2. header("Location: http://benutzername:passwort@domain.ch/shop/admin/index.php");

        Es sendet eine inkorrekte URL, die Username/Paßwort enthält, an den _Client_.

        Ja, und diese Daten sendet er auch noch unverschlüsselt...
        Ich glaube, daß der aktuelle MSIE unter WinXP mit SP2 diese Form des Seitenaufrufes mit Login nicht mehr zuläßt. Nach irgendeinem Sicherheitsupdate funktionierte das nicht mehr, wenn ich mich recht erinnere.
        100% sicher bin ich mir da nicht, aber in jedem Fall kann man sich nicht drauf verlassen, daß dieser Login so mit jedem Browser funktioniert.
        Insofern sollte man sich besser etwas anderes einfallen lassen.

        Gruß,
        rob

  2. Hi,

    Kann mir jemand sagen, weshalb sich das Ganze so verhält? Gibt es eine Möglichkeit dies zu umgehen?

    Sind beide Bereiche unter demselben Hostnamen?
    Sind für beide Bereiche dieselben Realm-Names verwendet worden?
    Ist die Datei mit den Usernamen/Passwörtern dieselbe?

    Daß http://benutzername:passwort@domain.ch/shop/admin/index.php wegen Username/Paßwort keine gültige URL ist, ist Dir bewußt? Ob ein Browser Weiterleitungen auf solche URLs durchführt, hängt vom Browser und dessen Konfiguration ab.

    cu,
    Andreas

    --
    Warum nennt sich Andreas hier MudGuard?
    Schreinerei Waechter
    O o ostern ...
    Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.