nicht angemeldet
ErrorDocument 401 http://xyz.de - funzt nicht
Hallo zusammen,
vielleicht hatte einer auch schon einmal dieses Problem:
ErrorDocument 403 http://xyz.de - funzt
ErrorDocument 401 http://xyz.de - funzt nicht (?)
Wie kann ich Apache dazu bewegen auch 401er auf xyz.de umzuleiten ?
Danke im Voraus.
Greetings
Torwächter
-
Hi,
vielleicht hatte einer auch schon einmal dieses Problem:
nein, denn wir können die Apache-Dokumentation der Direktive ErrorDocument unter http://httpd.apache.org/ lesen. Dort ist die Ursache Deines Problems sogar in Fettschrift genannt.
Wie kann ich Apache dazu bewegen auch 401er auf xyz.de umzuleiten ?
Wenn Du darüber nachdenkst, was ein 401 bedeutet und wann er gesendet wird, wird Dir klar werden, warum das nicht gehen _darf_.
Cheatah
-
Hmm so komm ich nicht weiter.
Also dann mal, was ich versuche:ich möchte ein Ordner mit htaccess schützen, sodass nur eine bestimmte ip ODER User mit gültigem Namen und Pass rein kommen.
Problem: wenn einer keine gültige IP hat erscheint der Pass-Dialog nach 3 mal falscher Eingabe kommt dann 401 aber ich möchte die User zu einer anderen Seite weiterleiten (nicht auf meinem Server)Vielleicht kennst du eine andere Lösung ?
Greetings
Torwächter-
Hi,
Problem: wenn einer keine gültige IP hat erscheint der Pass-Dialog nach 3 mal falscher Eingabe kommt dann 401
dann hast Du etwas grundsätzliches falsch konfiguriert. Es müsste ein 403 Forbidden kommen, kein 401 Unauthorized.
Cheatah
-
Hallo,
Problem: wenn einer keine gültige IP hat erscheint der Pass-Dialog nach 3 mal falscher Eingabe kommt dann 401
Dann den 401 auf eine lokale Datei umleiten, die dann Ihrerseits auf die gewünschte URL umleitet.
dann hast Du etwas grundsätzliches falsch konfiguriert. Es müsste ein 403 Forbidden kommen, kein 401 Unauthorized.
Nein, der 401 ist richtig. Du kannst beliebig oft versuchen, da rein zu kommen, so lange die Daten nicht stimmen, liefert der Server 'nen 401. Sonst könntest Du nach 3x falschem Pass ja nicht wieder neu versuchen. ;)
Cheatah
-
Hi,
Dann den 401 auf eine lokale Datei umleiten, die dann Ihrerseits auf die gewünschte URL umleitet.
das resultiert in einem völligen Verlust des Authentication-Mechanismus'.
dann hast Du etwas grundsätzliches falsch konfiguriert. Es müsste ein 403 Forbidden kommen, kein 401 Unauthorized.
Nein, der 401 ist richtig. Du kannst beliebig oft versuchen, da rein zu kommen, so lange die Daten nicht stimmen, liefert der Server 'nen 401. Sonst könntest Du nach 3x falschem Pass ja nicht wieder neu versuchen. ;)Solange ein 401 kommt, ist der Server bereit, eine Authentifizierung entgegenzunehmen.
Cheatah
-
Hallo Cheatah,
Dann den 401 auf eine lokale Datei umleiten, die dann Ihrerseits auf die gewünschte URL umleitet.
das resultiert in einem völligen Verlust des Authentication-Mechanismus'.
Wieso? Die Passwörter werden per Basic Auth zwischen Server und Client hin und her geschoben und wenn das Passwort falsch ist, schickt ihn eine Datei im Realm vom Server weg.
Wenn er nen 401 auf eine Fremd-URL umleiten will, ist das m.E. der einzige Weg.dann hast Du etwas grundsätzliches falsch konfiguriert. Es müsste ein 403 Forbidden kommen, kein 401 Unauthorized.
Nein, der 401 ist richtig. Du kannst beliebig oft versuchen, da rein zu kommen, so lange die Daten nicht stimmen, liefert der Server 'nen 401. Sonst könntest Du nach 3x falschem Pass ja nicht wieder neu versuchen. ;)Solange ein 401 kommt, ist der Server bereit, eine Authentifizierung entgegenzunehmen.
Korrekt. So soll es auch sein. Denn 403 heisst: Für Dich Zugriff verboten. 401 heisst: Du kannst/konnstest Deine Berechtigung nicht nachweisen. Sind zwei verschiedene Fehler.
Dass der Server die Versuchsanzahl nicht irgendwie sammelt, finde ich da: http://httpd.apache.org/docs/howto/auth.html#basicfaq.
Und hier: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html steht:
If the request already included Authorization credentials, then
the 401 response indicates that authorization has been refused for
those credentials. If the 401 response contains the same challenge
as the prior response, and the user agent has already attempted
authentication at least once, then the user SHOULD be presented
the entity that was given in the response, since that entity might
include relevant diagnostic information.Somit kommt bei Auth immer der 401, selbst bei Serverfehlern in diesem Zusammenhang. Wenn der 401 trotz übergebenen Daten kommt, sind diese falsch. Weswegen m.W. die meisten Browser nach 3 Versuchen aufhören. Oder irre ich mich da?
Gruss, Thoralf
-
Hi,
das resultiert in einem völligen Verlust des Authentication-Mechanismus'.
Wieso? Die Passwörter werden per Basic Auth zwischen Server und Client hin und her geschoben und wenn das Passwort falsch ist, schickt ihn eine Datei im Realm vom Server weg.
Wenn er nen 401 auf eine Fremd-URL umleiten will, ist das m.E. der einzige Weg.ein ErrorDocument http://... führt zu einem Redirect zu einem anderen Server, also zu einem Status: 3xx, welchen der Client erhält. Da ist von 401 nicht mehr die Spur zu sehen. Und das ist gut so, denn andernfalls würde der Client sich beim Fremdserver zu authentifizieren versuchen, wovon der Originalserver nichts hätte - und der Client auch nicht.
Solange ein 401 kommt, ist der Server bereit, eine Authentifizierung entgegenzunehmen.
Korrekt. So soll es auch sein. Denn 403 heisst: Für Dich Zugriff verboten. 401 heisst: Du kannst/konnstest Deine Berechtigung nicht nachweisen. Sind zwei verschiedene Fehler.Richtig, und genau das ist auch gewollt.
Dass der Server die Versuchsanzahl nicht irgendwie sammelt, finde ich da: http://httpd.apache.org/docs/howto/auth.html#basicfaq.
Grundkenntnisse über HTTP reichen, um das zu wissen.
Somit kommt bei Auth immer der 401, selbst bei Serverfehlern in diesem Zusammenhang. Wenn der 401 trotz übergebenen Daten kommt, sind diese falsch. Weswegen m.W. die meisten Browser nach 3 Versuchen aufhören. Oder irre ich mich da?
Korrekt, das ist aber eine Sache des Browsers. Andere verhalten sich anders.
Cheatah
-
Hallo,
das resultiert in einem völligen Verlust des Authentication-Mechanismus'.
Wieso? Die Passwörter werden per Basic Auth zwischen Server und Client hin und her geschoben und wenn das Passwort falsch ist, schickt ihn eine Datei im Realm vom Server weg.
Wenn er nen 401 auf eine Fremd-URL umleiten will, ist das m.E. der einzige Weg.ein ErrorDocument http://... führt zu einem Redirect zu einem anderen Server, also zu einem Status: 3xx, welchen der Client erhält. Da ist von 401 nicht mehr die Spur zu sehen. Und das ist gut so, denn andernfalls würde der Client sich beim Fremdserver zu authentifizieren versuchen, wovon der Originalserver nichts hätte - und der Client auch nicht.
Alles richtig, aber das ganze mit einem lokalen Perl- oder PHP-Script zu machen, was einen ordentlicher 3er Redirect macht, hab ich ihm schon zugetraut. ;)
Solange ein 401 kommt, ist der Server bereit, eine Authentifizierung entgegenzunehmen.
Korrekt. So soll es auch sein. Denn 403 heisst: Für Dich Zugriff verboten. 401 heisst: Du kannst/konnstest Deine Berechtigung nicht nachweisen. Sind zwei verschiedene Fehler.
Richtig, und genau das ist auch gewollt.Wieso sollte dann bei fehlerhafter Auth ein 403 kommen?
Somit kommt bei Auth immer der 401, selbst bei Serverfehlern in diesem Zusammenhang. Wenn der 401 trotz übergebenen Daten kommt, sind diese falsch. Weswegen m.W. die meisten Browser nach 3 Versuchen aufhören. Oder irre ich mich da?
Korrekt, das ist aber eine Sache des Browsers. Andere verhalten sich anders.
Hab ich nichts anderes behauptet.
Cheatah
Gruss, Thoralf
-
Hi,
ein ErrorDocument http://... führt zu einem Redirect zu einem anderen Server, also zu einem Status: 3xx, welchen der Client erhält. Da ist von 401 nicht mehr die Spur zu sehen. Und das ist gut so, denn andernfalls würde der Client sich beim Fremdserver zu authentifizieren versuchen, wovon der Originalserver nichts hätte - und der Client auch nicht.
Alles richtig, aber das ganze mit einem lokalen Perl- oder PHP-Script zu machen, was einen ordentlicher 3er Redirect macht, hab ich ihm schon zugetraut. ;)wenn er das macht, *existiert* *keine* *Authentication* *mehr*! Diese findet ausschließlich auf dem Originalserver statt, welcher immer(!) dann, wenn sich der User authentifizieren soll, das ErrorDocument 401 zum Client sendet. Wenn dies ein Redirect auf einen Fremdserver ist, dann ist das ein Redirect und *keine* Authentication mehr.
Richtig, und genau das ist auch gewollt.
Wieso sollte dann bei fehlerhafter Auth ein 403 kommen?Weil Torwächter eine Fehlerseite bei einem anderen Server haben möchte. Das impliziert, dass der Zugriff verwehrt wurde, also 403.
Cheatah
-
Hallo Cheatah,
wenn er das macht, *existiert* *keine* *Authentication* *mehr*! Diese findet ausschließlich auf dem Originalserver statt, welcher immer(!) dann, wenn sich der User authentifizieren soll, das ErrorDocument 401 zum Client sendet. Wenn dies ein Redirect auf einen Fremdserver ist, dann ist das ein Redirect und *keine* Authentication mehr.
Wieso nicht? Die ersetzte 401-Seite wird doch erst 'angezeigt', wenn wenigstens einmal die Authentifizierung fehlgeschlagen ist. Der Server schickt den 401 als Antwort auf eine normale Anfrage. Der Client muss jetzt mit einem Auth-Header antworten und kann dabei die Request wiederholen. Wird erneut mit 401 geantwortet, waren die Auth-Daten ungültig. Nach meinem Verständnis wird doch frühestens jetzt die 401er-Entity angezeigt, ob nun die NCSA Originale oder eine veränderte, spielt doch erst hier eine Rolle. Und wenn nun Serverseitig die nächste Anfrage mit einem 3er-Status beantwortet wird, dann steht doch einem Redirect nichts im Wege.
Wenn aber die Daten richtig waren, landet der Client doch auf der geschützten Seite.Wenn ein ErrorDocument 401 LokaleURI so funktionieren würde, wie Du fragst, würde sofort die entsprechende Fehlermeldung angezeigt und der Client wäre gezwungen, die Request mit Auth-Header zu wiederholen. Er kann aber auch nur mit Auth-Header ohne erneute Request antworten.
Dass ein direkter Redirect nicht geht, ist mir klar, dann würde der Client den 401 nicht zu sehen bekommen. Aber wenn der Client einen 401 bekommt, falsch beantwortet und als Reaktion statt eines 401 mit Informationen einen 303 oder 302 bekommt, sollte das doch kein Problem sein?
Richtig, und genau das ist auch gewollt.
Wieso sollte dann bei fehlerhafter Auth ein 403 kommen?Weil Torwächter eine Fehlerseite bei einem anderen Server haben möchte. Das impliziert, dass der Zugriff verwehrt wurde, also 403.
Klar, aber das macht nicht der Server, sondern dafür müsste er sorgen, zur Not mit einem serverinternen Redirect auf ein deny all- Verzeichnis.
Steh ich grade auf dem Schlauch?
Cheatah
Gruss, Thoralf
-
Hi,
wenn er das macht, *existiert* *keine* *Authentication* *mehr*! Diese findet ausschließlich auf dem Originalserver statt, welcher immer(!) dann, wenn sich der User authentifizieren soll, das ErrorDocument 401 zum Client sendet. Wenn dies ein Redirect auf einen Fremdserver ist, dann ist das ein Redirect und *keine* Authentication mehr.
Wieso nicht? Die ersetzte 401-Seite wird doch erst 'angezeigt', wenn wenigstens einmal die Authentifizierung fehlgeschlagen ist.
die erste fehlgeschlagene Authetifizierung ist der Versuch, die Ressource _ohne_ Authentifizierung anzufordern.
Der Server schickt den 401 als Antwort auf eine normale Anfrage. Der Client muss jetzt mit einem Auth-Header antworten und kann dabei die Request wiederholen. Wird erneut mit 401 geantwortet, waren die Auth-Daten ungültig. Nach meinem Verständnis wird doch frühestens jetzt die 401er-Entity angezeigt,
Was der Browser Dir in seinem Fenster anzeigt, ist für HTTP völlig unerheblich. Der Client schickt eine Anfrage an den Server; dieser stellt fest, dass sich der Client bitteschön zu authentifizieren hat und sendet einen 401; der Client kann daraufhin entweder aufgeben oder den User um entsprechende Daten bitten; im zweiten Fall beginnt der Vorgang erneut. HTTP kennt kein "erstes Mal", sondern nur das "jetzt", welches immer gleich funktioniert. Das bedeutet auch:
Schickt der Server dem Client eine Fehlerseite von einem anderen Server zurück, so lautet der Status 3xx, und von einem 401 erfährt der Client gar nichts mehr. Es *gibt* dann keine Authentication mehr, denn sie *kann* nicht mit einer Fehlerseite eines fremden Servers funktionieren. No way.
Wenn aber die Daten richtig waren, landet der Client doch auf der geschützten Seite.
Der Client erfährt gar nicht erst, dass es solche Daten zu versenden gibt.
Wenn ein ErrorDocument 401 LokaleURI so funktionieren würde, wie Du fragst, würde sofort die entsprechende Fehlermeldung angezeigt und der Client wäre gezwungen, die Request mit Auth-Header zu wiederholen.
Der Client gibt statt der Fehlerseite einfach eine Login-Box aus. Das ist aber _seine_ Entscheidung.
Dass ein direkter Redirect nicht geht, ist mir klar, dann würde der Client den 401 nicht zu sehen bekommen. Aber wenn der Client einen 401 bekommt, falsch beantwortet und als Reaktion statt eines 401 mit Informationen einen 303 oder 302 bekommt, sollte das doch kein Problem sein?
Dazu muss der 401 aber lokal sein. HTTP besteht _nur_ aus Request und Response, nicht aus Request und Response mit der Option eines weiteren Request. Dazu müsste HTTP verbindungsbehaftet sein, und das ist es nicht.
Wieso sollte dann bei fehlerhafter Auth ein 403 kommen?
Weil Torwächter eine Fehlerseite bei einem anderen Server haben möchte. Das impliziert, dass der Zugriff verwehrt wurde, also 403.
Klar, aber das macht nicht der Server,Ein 403 kommt vom Server. Es ist der Status eines Response-Headers.
sondern dafür müsste er sorgen, zur Not mit einem serverinternen Redirect auf ein deny all- Verzeichnis.
Diesen Teil verstehe ich nicht.
Steh ich grade auf dem Schlauch?
Ich glaube, es fehlt wirklich nur der "klick"-Effekt :-)
Die Tatsache, dass die Apache-Entwickler in der ErrorDocument-Doku in Fettdruck geschrieben haben, dass absolute URIs bei 401 nicht erlaubt sind, hat nichts damit zu tun, dass die Leute nicht programmieren können. Es ergibt sich einfach aus der technischen Notwendigkeit, aus der Funktionsweise von HTTP. Ein 'ErrorDocument 401 http://...' *geht einfach nicht*, es ergibt keinen Sinn. Es würde notwendigerweise dazu führen, dass *jeder* 401 mit einem 403 identisch ist, das also der Zugang zu einem authentifizierten Bereich bereits verwehrt wird, bevor der Client überhaupt davon erfährt, dass er sich authentifizieren soll.
Cheatah
-
Hallo allerseits,
Steh ich grade auf dem Schlauch?
Ich glaube, es fehlt wirklich nur der "klick"-Effekt :-)
Die Tatsache, dass die Apache-Entwickler in der ErrorDocument-Doku in Fettdruck geschrieben haben, dass absolute URIs bei 401 nicht erlaubt sind, hat nichts damit zu tun, dass die Leute nicht programmieren können. Es ergibt sich einfach aus der technischen Notwendigkeit, aus der Funktionsweise von HTTP. Ein 'ErrorDocument 401 http://...' *geht einfach nicht*, es ergibt keinen Sinn. Es würde notwendigerweise dazu führen, dass *jeder* 401 mit einem 403 identisch ist, das also der Zugang zu einem authentifizierten Bereich bereits verwehrt wird, bevor der Client überhaupt davon erfährt, dass er sich authentifizieren soll.
Yep, Du hast Recht, ich hab das einfach mal probiert. Wenn das ErrorDocument einen eigenen Response-Header sendet, wird dieser nicht nur gerendert, sondern SOFORT gesendet. Damit kommt der 401 nie beim Client an. Es bleibt also nur die Weiterleitung per HTML/META mit allen Risiken.
Nur der Klarstellung wegen, ich find die Lösung unsinnig. Aber ich dachte eben, es wäre technisch möglich. ;)
Cheatah
Gruss, Thoralf
-
-
-
Moin,
Richtig, und genau das ist auch gewollt.
Wieso sollte dann bei fehlerhafter Auth ein 403 kommen?Weil Torwächter eine Fehlerseite bei einem anderen Server haben möchte. Das impliziert, dass der Zugriff verwehrt wurde, also 403.
Diese Stelle verstehe ich bei deinem Posting nicht.
Beim Rest kann ich dein Missverständnis aber erkennen: Torwächter möchte den Zugriff bei korrekter IP-Addresse oder korrektem Passwort gewähren. Das war grade im Forum (ich glaube Andreas hatte gefragt) und wird beim Apache mit Satisfy any gemacht. Wenn die IP-Addresse aus dem zugelassenen Bereich kommt, wird der Request sofort beantwortet, wenn nicht, wird zunächst das Passwort überprüft und ggbf. mit 401 geantwortet. 403 hat hier an keiner Stelle irgendetwas zu suchen.
Was den zweiten Teil (Umleitung bei 401) angeht: Das kann man auch ohne Redirect-Status (und damit ErrorDocument 401 http://..) machen, zum Beispiel mit Refresh: 0; URL=http://... Von Skripten die versuchen manchmal bei einem falschen Passwort etwas anderes als 401 zu senden, halte ich in der Regel nichts.
--
Henryk Plötz
Grüße von der Ostsee-
Hi,
Weil Torwächter eine Fehlerseite bei einem anderen Server haben möchte. Das impliziert, dass der Zugriff verwehrt wurde, also 403.
Diese Stelle verstehe ich bei deinem Posting nicht.
Beim Rest kann ich dein Missverständnis aber erkennen: Torwächter möchte den Zugriff bei korrekter IP-Addresse oder korrektem Passwort gewähren. Das war grade im Forum (ich glaube Andreas hatte gefragt) und wird beim Apache mit Satisfy any gemacht. Wenn die IP-Addresse aus dem zugelassenen Bereich kommt, wird der Request sofort beantwortet, wenn nicht, wird zunächst das Passwort überprüft und ggbf. mit 401 geantwortet. 403 hat hier an keiner Stelle irgendetwas zu suchen.
403 war nicht gefordert; er ergibt sich jedoch aus der Forderung. Mir ist schon klar, dass Torwächter keinen 403 haben möchte - das, was er sich vorstellt, lässt sich jedoch nur mit einem solchen Status realisieren, bzw. mit etwas, das diesem Status entspricht (ein ErrorDocument eines externen Servers ist in letzter Konsequenz zumeist ein 200, auch wenn der Request von einem 404 oder 500 oder was auch immer stammte).
Was den zweiten Teil (Umleitung bei 401) angeht: Das kann man auch ohne Redirect-Status (und damit ErrorDocument 401 http://..) machen, zum Beispiel mit Refresh: 0; URL=http://...
Ähm... häh? Mir ist schon klar, dass Du einen <meta http-equiv> meinst; dieser jedoch stellt (daher der Name) ein HTTP-Äquivalent dar, nämlich einen 3xx-Status. Was das hier für eine Bedeutung haben soll, ist mir nicht ganz klar.
Von Skripten die versuchen manchmal bei einem falschen Passwort etwas anderes als 401 zu senden, halte ich in der Regel nichts.
Ich schon: nämlich Abstand ;-)
Cheatah
-
Moin,
403 war nicht gefordert; er ergibt sich jedoch aus der Forderung.
Ok, zusammen mit deinem anderen Posting ist mir das klar geworden.
Ähm... häh? Mir ist schon klar, dass Du einen <meta http-equiv> meinst; dieser jedoch stellt (daher der Name) ein HTTP-Äquivalent dar, nämlich einen 3xx-Status. Was das hier für eine Bedeutung haben soll, ist mir nicht ganz klar.
Ok, war blöd formuliert und ich konnte mich nicht ganz daran erinnern wie ich das gelöst hatte, das hatte ich nämlich schonmal (komplett anderer Kontext aber ähnliches Problem). Ich habe den Code zwar nicht wiedergefunden, aber die Erinnerung kehrt wieder:
Mach ein ganz normales ErrorDocument 401 /lala/der/pfad/zu/401.html und in diese Datei schreibst du dann in das Head-Element <meta http-equiv="Refresh" content="0; URL=http://anderer.server/pfad/zur/anderen/401.html"> (den entsprechenden HTTP-Header, also Refresh: 0; URL=..., zu senden müsste auch gehen, habe ich aber nicht getestet) und schon ist das Gewünschte erreicht. Alle Browser denen ich das eben in einem Schnelltest vorgeworfen habe (Mozilla 1.1, IE 5.5, Opera 6) haben es wunschgemäß gefressen.Im Fehlerfall (und nur dann) wird das 401-ErrorDocument von deinem Server gerendert (geladen wird es in jedem Fall) und dann wird der Refresh aktiv und leitet sofort auf die Seite auf dem anderen Server um. Je nach Browser- und Netzgeschwindigkeit blinkt deine Seite nur mal kurz auf oder ist gar nicht zu sehen. Das Ganze ohne jeglichen 3xx-Status, im Zweifelsfalle funktioniert also höchstens die Umleitung nicht (für den Fall solltest du einen Link auf die andere Seite bereithalten), die Authentifizierung läuft unbeeinflusst ab.
--
Henryk Plötz
Grüße von der Ostsee-
Hi,
Mach ein ganz normales ErrorDocument 401 /lala/der/pfad/zu/401.html und in diese Datei schreibst du dann in das Head-Element <meta http-equiv="Refresh" content="0; URL=http://anderer.server/pfad/zur/anderen/401.html">
ah, jetzt, ja. Okay, das kann(!) funktionieren; allerdings gibt es Systeme (z.B. das Perl-Modul LWP::Simple), die u.U. daraus "echte" HTTP-Header machen, und das nicht ganz zu Unrecht. Soweit ich die Definitionen im Überblick habe kann man keinesfalls ausschließen, dass ein (z.B. auch zukünftiger) Browser sich ebenso verhalten wird - und schon haben wir wieder den Salat.
Je nach Browser- und Netzgeschwindigkeit blinkt deine Seite nur mal kurz auf oder ist gar nicht zu sehen.
Oder aber, wenn der Browser (z.B. Opera) so konfiguriert ist, wird _nur_ die (leere?) 401-Seite angezeigt. Ein in HTML-notierter Redirect ist in keine Richtung sicher - er kann sowohl automatisch als auch gar nicht ausgeführt werden.
Aber stimmt, das ist eine Idee.
Cheatah
-
-
-
-
-
-
-
-
-
-
-
-