Apache2 und HTTP Authentifizierung

[Gunther]

Hallo werte Selfgemeinde!

Ich stehe für mich das erste Mal vor der Aufgabe, einen gesamten Bereich einer Website mit einem (einfachen) Zugangsschutz zu versehen.

Dieses möchte ich (weitestgehend) dem Webserver (Apache2.2) überlassen per mod_auth, da ich kein Session basiertes System verwenden möchte.

Meine Frage:
Sehe ich das richtig, dass sich in diesem Fall die Eingabe von Benutzername und Passwort_nur_über das vom jeweiligen Browser automatisch öffnende Eingabefenster (wie bei der Anmeldung hier im Forum) realisieren lässt?
Oder gibt es auch noch alternative Möglichkeiten dem Apache diese Informationen "unterzujubeln"?

Für eure Hilfe meinen besten Dank im Voraus!

Gruß Gunther

[Felix Riesterer]

Lieber Gunther,

Sehe ich das richtig, dass sich in diesem Fall die Eingabe von Benutzername und Passwort_nur_über das vom jeweiligen Browser automatisch öffnende Eingabefenster (wie bei der Anmeldung hier im Forum) realisieren lässt?

Nein. Es ist aber die in Deinem Fall sinnvollste und einfachste Lösung.

Oder gibt es auch noch alternative Möglichkeiten dem Apache diese Informationen "unterzujubeln"?

Nein, dem Apachen nicht. Aber lass uns lieber nicht weiter darüber nachdenken. Bleibe lieber bei Deiner Authentifizierung über .htaccess.

Liebe Grüße,

Felix Riesterer.

[Gunther]

Lieber Felix,

vielen Dank für deine Antwort.

Sehe ich das richtig, dass sich in diesem Fall die Eingabe von Benutzername und Passwort_nur_über das vom jeweiligen Browser automatisch öffnende Eingabefenster (wie bei der Anmeldung hier im Forum) realisieren lässt?

Nein. Es ist aber die in Deinem Fall sinnvollste und einfachste Lösung.

Soweit OK. Da ich aber von Hause aus ein neugieriger & wissbegieriger Typ bin: Wie lauten denn die Stichworte zu den alternativen Möglichkeiten? ;-)

Meine ganze Fragerei & Überlegerei zielt eigentlich darauf ab, ob es auch eine Variante mit einem "klassischen" Login über eine entsprechende Seite gibt (weil das ggf. für die angepeilte Zielgruppe, die nicht unbedingt als besonders interneterfahren bezeichnet werden kann, "einfacher/ benutzerfreundlicher ist).

Soweit ich das System der HTTP Authentifizierung bisher verstanden habe, geht es ja darum, die Information von Benutzername/ -ID und Passwort in den entsprechenden (speziellen) Browsercache zu bekommen, damit dieser die Informationen bei jedem Request mitsendet.

Gruß Gunther

[ChrisB]

Hi,

Meine ganze Fragerei & Überlegerei zielt eigentlich darauf ab, ob es auch eine Variante mit einem "klassischen" Login über eine entsprechende Seite gibt

Es gibt bspw. mod_auth_cookie

(weil das ggf. für die angepeilte Zielgruppe, die nicht unbedingt als besonders interneterfahren bezeichnet werden kann, "einfacher/ benutzerfreundlicher ist).

Einen Benutzernamen und ein Passwort in eine entsprechende Maske einzugeben, sollten auch unerfahrene Benutzer hinkriegen.

Ausserdem bleiben unerfahrene Benutzer unerfahrene Benutzer, wenn du ihnen nicht ab und zu mal etwas neues zeigst.

Soweit ich das System der HTTP Authentifizierung bisher verstanden habe, geht es ja darum, die Information von Benutzername/ -ID und Passwort in den entsprechenden (speziellen) Browsercache zu bekommen, damit dieser die Informationen bei jedem Request mitsendet.

Das geht ggf. auch noch per AJAX.
(Allerdings braucht es ein serverseitiges Script, welches die Daten in einem ersten Durchlauf auf Korrektheit prüft - sonst gibt's dabei auch wieder den Dialog, den du vermeiden möchtest.)

MfG ChrisB

[Gunther]

Hi Chris,

auch dir erstmal vielen Dank für deine Antwort.

Meine ganze Fragerei & Überlegerei zielt eigentlich darauf ab, ob es auch eine Variante mit einem "klassischen" Login über eine entsprechende Seite gibt

Es gibt bspw. mod_auth_cookie

Hmmm ..., das erspart dem Besucher aber lediglich bei einem erneuten Besuch die Eingabe von Benutzername und Passwort, sofern der/ das Cookie dann noch vorhanden nicht (und ich das richtig verstanden habe).
Aber immerhin wäre es eine zusätzliche Option, die imho keine Nachteile mit sich bringt und ggf. eben einen kleinen Zugewinn an Benutzerfreundlichkeit haben kann.

(weil das ggf. für die angepeilte Zielgruppe, die nicht unbedingt als besonders interneterfahren bezeichnet werden kann, "einfacher/ benutzerfreundlicher ist).

Einen Benutzernamen und ein Passwort in eine entsprechende Maske einzugeben, sollten auch unerfahrene Benutzer hinkriegen.

Ja, wohl war! Aber du kennst das mit der Apotheke und den Pferden ...?

Ausserdem bleiben unerfahrene Benutzer unerfahrene Benutzer, wenn du ihnen nicht ab und zu mal etwas neues zeigst.

Auch richtig. Aber hier handelt es sich (um einen der seltenen Fälle ;-) ), wo es nur darauf ankommt, dass der jeweilige Besucher möglichst direkt, einfach und ohne Umwege an die entsprechenden Inhalte gelangt (und das unabhängig von seiner jeweiligen Interneterfahrung). Es steht auch zu befürchten, dass die überwiegende Mehrheit der potentiellen Zielgruppe mit IEs unterwegs ist.

Soweit ich das System der HTTP Authentifizierung bisher verstanden habe, geht es ja darum, die Information von Benutzername/ -ID und Passwort in den entsprechenden (speziellen) Browsercache zu bekommen, damit dieser die Informationen bei jedem Request mitsendet.

Das geht ggf. auch noch per AJAX.
(Allerdings braucht es ein serverseitiges Script, welches die Daten in einem ersten Durchlauf auf Korrektheit prüft - sonst gibt's dabei auch wieder den Dialog, den du vermeiden möchtest.)

Das setzt aber dann wieder aktiviertes JS voraus und scheidet somit direkt aus, denn die (clientseitigen) Voraussetzungen müssen minimal gehalten werden.

Meine (vage) Idee war die, dass man evt. über ein HTML-Formular die Daten für Benutzername und Passwort zum Server transportieren kann, wo sie per PHP (nach vorheriger Prüfung) dem Apache "mitgeteilt" werden (etwa per apache_setenv), per Location-Header weitergeleitet wird und der Apache per Rewrite-Condition (eben der Umgebungsvariable) den Zugriff erlaubt oder eben unterbindet.

Aber irgendwie erscheint mir das selber schon als "von hinten durch die Brust ins Auge". Geh' ich halt mal davon aus, dass auch der letzte Depp mit der Browser-Eingabemaske zurechtkommt.

Gruß Gunther

[Der Martin]

Hallo,

Meine (vage) Idee war die, dass man evt. über ein HTML-Formular die Daten für Benutzername und Passwort zum Server transportieren kann, wo sie per PHP (nach vorheriger Prüfung) dem Apache "mitgeteilt" werden (etwa per apache_setenv), ...

und damit bist du doch schon fast am Ziel: Jetzt noch eine Session aufmachen und die Information "Benutzerdaten OK" dort ablegen, fertig. Dann kannst du HTTP-AUTH entsorgen[1].
Dann hättest du -falls das von Belang ist- sogar die Möglichkeit, ein explizites Abmelden anzubieten, was bei HTTP-AUTH nur mit Klimmzügen möglich ist (und durch seine Nebenwirkungen ggf. den Nutzer verwirrt).

per Location-Header weitergeleitet wird und der Apache per Rewrite-Condition (eben der Umgebungsvariable) den Zugriff erlaubt oder eben unterbindet.

Das geht nicht. Es gibt AFAIK keinen Weg, die Zugangsdaten dem Client wieder zurückzuliefern, so dass er sie für Folgerequests speichert.

Aber irgendwie erscheint mir das selber schon als "von hinten durch die Brust ins Auge".

Hört sich für mich auch so an.

Ciao,
 Martin

[1] Obacht: Bei einem rein sessionbasierten Login ohne HTTP-AUTH ist nur der Zugriff auf die (Script-)Ressourcen geschützt, die die Voraussetzungen von sich aus überprüfen! Der Zugriff auf andere Ressourcen wie Bilder oder statische HTML-Dateien "am Login vorbei" ist trotzdem möglich. Kann mit mod_rewrite und weiterer Scriptlogik abgedichtet werden, aber das ist eben wieder zusätzlicher Aufwand.

[Gunther]

Hallo Martin,

Meine (vage) Idee war die, dass man evt. über ein HTML-Formular die Daten für Benutzername und Passwort zum Server transportieren kann, wo sie per PHP (nach vorheriger Prüfung) dem Apache "mitgeteilt" werden (etwa per apache_setenv), ...

und damit bist du doch schon fast am Ziel: Jetzt noch eine Session aufmachen und die Information "Benutzerdaten OK" dort ablegen, fertig. Dann kannst du HTTP-AUTH entsorgen[1].

Sessions sind aber (wie schon geschrieben) genau das, was ich vermeiden möchte (da Sessions für mich nur dann "akzeptabel" sind, wenn man die Annahme von Cookies voraussetzen kann, was in diesem Fall hier nicht möglich ist).

Dann hättest du -falls das von Belang ist- sogar die Möglichkeit, ein explizites Abmelden anzubieten, was bei HTTP-AUTH nur mit Klimmzügen möglich ist (und durch seine Nebenwirkungen ggf. den Nutzer verwirrt).

Ja, diese Problematik ist mir bekannt. Aber in diesem Fall nicht tragisch, da ja der gesamte Bereich geschützt werden soll und keine Notwendigkeit für ein Ausloggen des Users besteht.

per Location-Header weitergeleitet wird und der Apache per Rewrite-Condition (eben der Umgebungsvariable) den Zugriff erlaubt oder eben unterbindet.

Das geht nicht. Es gibt AFAIK keinen Weg, die Zugangsdaten dem Client wieder zurückzuliefern, so dass er sie für Folgerequests speichert.

Ja, das ist wohl leider das Problem. Deshalb bekommt man die Authentifizierungs-Informationen nur über die jeweilige Browser-Eingabemaske in dessen speziellen Cache dafür.

[1] Obacht: Bei einem rein sessionbasierten Login ohne HTTP-AUTH ist nur der Zugriff auf die (Script-)Ressourcen geschützt, die die Voraussetzungen von sich aus überprüfen! Der Zugriff auf andere Ressourcen wie Bilder oder statische HTML-Dateien "am Login vorbei" ist trotzdem möglich. Kann mit mod_rewrite und weiterer Scriptlogik abgedichtet werden, aber das ist eben wieder zusätzlicher Aufwand.

Ja, danke für den Hinweis (ist mir sogar auch schon klar gewesen ;-) ). Dann kann man aber imho eben lieber gleich den Apache die ganze Arbeit machen lassen und hat Null Extra-Aufwand (und mögliche Fehlerquellen/ Löcher im System).

Dank & Gruß
Gunther

[Felix Riesterer]

Lieber Gunther,

Sessions sind aber (wie schon geschrieben) genau das, was ich vermeiden möchte (da Sessions für mich nur dann "akzeptabel" sind, wenn man die Annahme von Cookies voraussetzen kann, was in diesem Fall hier nicht möglich ist).

der Session-Mechanismus von PHP kennt ein Fallback, das bei Keksverweigerern einen URL-Parameter benutzt. Anstatt
"http://example.org/meine_seite.html"
heißt es dann eben
"http://example.org/meine_seite.html?PHPSESSID=ab241n2k3r7bfa7241vgasd8"
oder so ähnlich. Diesen URL-Parameter kann PHP selbständig an href-Attributwerte und an action-Attributwerte anhängen (wenn in den PHP-Einstellungen "session.use_trans_sid" nicht auf 0 gesetzt ist). Wäre das akzeptabel?

Dann kann man aber imho eben lieber gleich den Apache die ganze Arbeit machen lassen und hat Null Extra-Aufwand (und mögliche Fehlerquellen/ Löcher im System).

Daher mein Vorschlag, nicht weiter über andere Möglichkeiten zu sinnieren. Ist Dir jetzt klar, warum ich das geschrieben hatte?

Liebe Grüße,

Felix Riesterer.

[Gunther]

Hi,

ich nochmal ...!

Es gibt bspw. mod_auth_cookie

Kann es sein, dass es das Modul für den Apache 2.2 (noch) nicht (mehr) gibt?
Google lieferte nämlich auch keine erschöpfende Auskunft.

Gruß Gunther

[Christian Seiler]

Hi Gunther,

Es gibt bspw. mod_auth_cookie
Kann es sein, dass es das Modul für den Apache 2.2 (noch) nicht (mehr) gibt?

Kann gut sein, da mit Apache 2.2 der ganze Authentifizierungs-Kram *stark* überarbeitet wurde und damit Dinge nicht mehr out-of-the-box funktionieren wie vorher (bei Apache 2.0 hat sich im Vergleich zu 1.3 nicht viel geändert in dieser Hinsicht).

Für die aktuelle Entwicklungsversion vom Apache (noch nicht mal im entferntesten produktionsreif!) gibt's mod_auth_form, mit der Du sowas machen kannst.

Viele Grüße,
Christian