Fehler 401 per Perl-Script abarbeiten

[TomC]

TWIMC:

----------------------------------------------------------

::Sachverhalt
Ich habe ein Verzeichnis mit .htaccess (im entsprechenden Verzeichnis) geschützt und fange per .htaccess (im Hauptverzeichnis) die Fehler 401, 403, 404 und 500 ab und leite Sie an ein Perl-Script weiter. Dieses Script ruft entweder die wahrscheinlichste Seite auf, schickt eine Mail an den Webmaster oder ruft eine Login-Seite auf usw..

::Mein Fehler
Beim Status 401 werden nur folgende Zeilen ausgeführt:

$new_url = "$path_pages/all/html/dc/login.html";
$html = $cgi->redirect($new_url);
print $html;

Das hat dazu geführt, dass die Login-Seite *immer* ausgerufen wurde, egal, wie ich eine Seite im geschützten Bereich aufgerufen habe. Es erschien nicht einmal die Box zur Eingabe von Username und Password. Selbst wenn ich die Seite mit
http://username:[e-mail]/geschuetzerbereich/file.html
aufgerufen habe, wurde nicht die aufgerufene Seite sondern die Login-Seite angezeigt. Wollte ich die Seite über die Login-Seite aufrufen, erschien wieder die Login-Seite....

::Lösung
Schließlich habe ich statt $html = $cgi->redirect($new_url); einen einfachen HTML-Code zusammengebastelt, in dem ein "refresh" und zur Sicherheit auch noch ein JavaScript zur Weiterleitung ausgeführt werden. Jetzt funktioniert es plötzlich: Rufe ich die geschützte Seite direkt auf, kommt die Eingabebox. 3 falsche Eingaben oder ein Abbruch ruft die Login-Seite auf und nach diesem LogIn wird die richtige Seite angezeigt.

----------------------------------------------------------------

Hat jemand eine Erklärung dafür?

Gruß von TomC

[Cheatah]

Hi,

Das hat dazu geführt, dass die Login-Seite *immer* ausgerufen wurde, egal, wie ich eine Seite im geschützten Bereich aufgerufen habe. Es erschien nicht einmal die Box zur Eingabe von Username und Password.

natürlich nicht. Der Client wurde (mit einem 3xx-Statuscode) auf eine Seite weitergeleitet, die nicht per 401-Status zu einem Loginvorgang aufforderte. Aus einem sehr ähnlichen Grund ist es nicht möglich, per ErrorDocument 401-Stati auf einen anderen Server zu schicken.

Selbst wenn ich die Seite mit
http://username:[e-mail]/geschuetzerbereich/file.html
aufgerufen habe,

Was Du hoffentlich nur privat gemacht hast, da diese URL technisch illegal und somit keinesfalls veröffentlichungstauglich ist.

Schließlich habe ich statt $html = $cgi->redirect($new_url); einen einfachen HTML-Code zusammengebastelt, in dem ein "refresh" und zur Sicherheit auch noch ein JavaScript zur Weiterleitung ausgeführt werden. Jetzt funktioniert es plötzlich:

Logisch. Der Client hat eine Seite mit Status 401 bekommen.

Hat jemand eine Erklärung dafür?

Mach Dir einfach nur klar, welche Header von wem zu wem geschickt werden, und wie darauf jeweils reagiert wird. Es ist alles absolut stimmig.

Cheatah

[TomC]

Selbst wenn ich die Seite mit
http://username:[e-mail]/geschuetzerbereich/file.html
aufgerufen habe,

Was Du hoffentlich nur privat gemacht hast, da diese URL technisch >>illegal und somit keinesfalls veröffentlichungstauglich ist.

Was meinst Du mit technisch illegal? Es gibt im medizinischen Bereich einen Zugangsberechtigungs-Dienst namens DocCheck. Die bieten unter anderem die Möglichkeit, dass man selbst einen Bereich mit .htaccess sichert. Möchte sich nun ein Arzt im geschützten Fachbereich Seiten ansehen, muss er sich erst auf einer speziellen Seite meiner Site anmelden. Ein Formular sendet Usernamen und Passwort des Arztes an DocCheck, dort werden die Daten überprüft und als Antwort wird eine URL gesendet in der Form:
http://username:[e-mail]/geschuetzerbereich/file.html
Somit erhält der Arzt Zugang zum geschützten Bereich.

Gruß von TomC

[Alexander Foken]

Moin Moin !

Was meinst Du mit technisch illegal?

Aaaaaaah! Du hast gefragt! Jetzt haut Dir Cheatah wieder die alte RFC um die Ohren, in der steht, daß HTTP- und HTTPS-URLs weder Usernamen noch Password enthalten dürfen. Es funktioniert trotzdem in allen mir bekannten Browsern!

Alexander

[Cheatah]

Hi,

Aaaaaaah! Du hast gefragt! Jetzt haut Dir Cheatah wieder die alte RFC um die Ohren, in der steht, daß HTTP- und HTTPS-URLs weder Usernamen noch Password enthalten dürfen.

*g* nein, ich verweise nur auf den "[e-mail]"-Thread etwas weiter oben :-)

Es funktioniert trotzdem in allen mir bekannten Browsern!

Kannst Du _garantieren_, dass es bei _jedem_ funktioniert, der die URL erhält? Und ich rede hier nicht von Personen, sondern von Clients.

Cheatah

[Alexander Foken]

Moin Moin !

Kannst Du _garantieren_, dass es bei _jedem_ funktioniert, der die URL erhält? Und ich rede hier nicht von Personen, sondern von Clients.

Natürlich nicht, denn Du könntest -- z.B. basierend auf Mozilla oder Lynx -- einen Browser bauen, der strikt RFC-konform ist und nur valides HTML akzeptiert.

Ich sage nur, daß alle Browser, die ich kenne, mit diesen nach RFC ungültigen URLs klarkommen. Das müßten so etwa die wichtigsten 10 Browser sein, damit sollte ich einen "Marktanteil" von mind. 90% haben.

Spielen wir das Spiel mal andersrum: Nenn mir einen nicht selbstgestrickten Browser, der mit user@password:host-URLs *nicht* klarkommt, sonst aber RFC-konform ist. (Technisch korrekt mußte es eigentlich "sonst auch RFC-konform" heißen.)

Alexander

[Cheatah]

Hi,

Kannst Du _garantieren_, dass es bei _jedem_ funktioniert, der die URL erhält? Und ich rede hier nicht von Personen, sondern von Clients.
Natürlich nicht, denn Du könntest -- z.B. basierend auf Mozilla oder Lynx -- einen Browser bauen, der strikt RFC-konform ist und nur valides HTML akzeptiert.

es gibt genügend Clients (warum immer die Einschränkung auf Browser?), deren Fehlerkorrekturen gering genug sind. Da brauche ich nicht noch extra etwas zu programmieren :-)

Ich sage nur, daß alle Browser, die ich kenne, mit diesen nach RFC ungültigen URLs klarkommen. Das müßten so etwa die wichtigsten 10 Browser sein, damit sollte ich einen "Marktanteil" von mind. 90% haben.

Ein Marktanteil von nicht *exakt* 100% ist bereits zu gering. Ein einziger Client, der einen einzigen Request ausführt reicht aus, um Schäden zu verursachen.

Spielen wir das Spiel mal andersrum: Nenn mir einen nicht selbstgestrickten Browser, der mit user@password:host-URLs *nicht* klarkommt,

Ich schätze mal, dass selbst bei Betrachtung jeder einzelnen veröffentlichten Version aller Browser diese Menge _höchstens_ einen einstelligen Prozentsatz der verschiedenen im Netz befindlichen Clients ausmacht, vermutlich sogar weniger als 1%. Es ist auch völlig unnötig, dass Du oder ich theoretisch an die Clientsoftware herankommen. Wichtig ist allein, dass sich solche Programme im Einsatz befinden.

sonst aber RFC-konform ist.

Diese Bedingung ist bar jeder Relevanz.

Cheatah

[Alexander Foken]

Moin Moin !

Kannst Du _garantieren_, dass es bei _jedem_ funktioniert, der die URL erhält? Und ich rede hier nicht von Personen, sondern von Clients.

[...]

Ich sage nur, daß alle Browser, die ich kenne, mit diesen nach RFC ungültigen URLs klarkommen. Das müßten so etwa die wichtigsten 10 Browser sein, damit sollte ich einen "Marktanteil" von mind. 90% haben.

Ein Marktanteil von nicht *exakt* 100% ist bereits zu gering.

Eigentlich suche ich ja nur den einen Browser, der mit user:pass@host nicht klarkommt. Der müßte sich also in den restlichen 10% Rumtreiben, damit habe ich den Suchbereich eingeschränkt.

Ein einziger Client, der einen einzigen Request ausführt reicht aus, um Schäden zu verursachen.

Ob es Schäden verursacht? Was soll schon passieren, wenn ein Browser http://user:[e-mail]/ nicht verdauen kann? Er versucht, den Hostnamen "user:pass@www" in der Domain "example.com" aufzulösen und fällt auf die Nase. Das wars.

Spielen wir das Spiel mal andersrum: Nenn mir einen nicht selbstgestrickten Browser, der mit user@password:host-URLs *nicht* klarkommt,

Ich schätze mal, dass selbst bei Betrachtung jeder einzelnen veröffentlichten Version aller Browser diese Menge _höchstens_ einen einstelligen Prozentsatz der verschiedenen im Netz befindlichen Clients ausmacht, vermutlich sogar weniger als 1%. Es ist auch völlig unnötig, dass Du oder ich theoretisch an die Clientsoftware herankommen. Wichtig ist allein, dass sich solche Programme im Einsatz befinden.

Dann nenne eines beim Namen! Du behauptest hier nur. Beweise es.

sonst aber RFC-konform ist.

Diese Bedingung ist bar jeder Relevanz.

Nein: Ich nenne /usr/bin/more einen Browser. "Beweis": /usr/bin/more http://user:[e-mail]/ funktioniert nicht. Wäre /usr/bin/more RFC-konform in meinem Sinne, dann würde wenigstens /usr/bin/more http://www.example.com/ funktionieren.

Alexander

[Cheatah]

Hi,

Eigentlich suche ich ja nur den einen Browser, der mit user:pass@host nicht klarkommt. Der müßte sich also in den restlichen 10% Rumtreiben, damit habe ich den Suchbereich eingeschränkt.

ah, okay. Nur: Warum?

Ob es Schäden verursacht? Was soll schon passieren, wenn ein Browser http://user:[e-mail]/ nicht verdauen kann? Er versucht, den Hostnamen "user:pass@www" in der Domain "example.com" aufzulösen und fällt auf die Nase. Das wars.

Woher weißt Du, dass er nicht tatsächlich den richtigen Hostnamen erkennt und dort die URL (ja, die ganze - das ist erlaubt) anfordert? Woher weißt Du, dass die dazwischen liegenden Systeme die URL nicht ebenfalls nutzen; etwa ein Proxy als Identifikation des Cache-Eintrags? Wie willst Du wissen, welches Fehlverhalten bei fehlerhaften Dingen zu erwarten ist?

Ich schätze mal, dass selbst bei Betrachtung jeder einzelnen veröffentlichten Version aller Browser diese Menge _höchstens_ einen einstelligen Prozentsatz der verschiedenen im Netz befindlichen Clients ausmacht, vermutlich sogar weniger als 1%. Es ist auch völlig unnötig, dass Du oder ich theoretisch an die Clientsoftware herankommen. Wichtig ist allein, dass sich solche Programme im Einsatz befinden.
Dann nenne eines beim Namen!

Den Robot von MeineK2wleSuchmaschiEneAusDemKostenlosenScriptarchiv.

Du behauptest hier nur. Beweise es.

Jeder Trottel kann einen Client bauen. Brauchst Du Beweise dazu, dass darunter auch einer ist, der es falsch macht?

sonst aber RFC-konform ist.
Diese Bedingung ist bar jeder Relevanz.
Nein:

Doch. Auch RFC-unkonforme Clients sind im Einsatz.

Ich nenne /usr/bin/more einen Browser.

Vergiss doch bitte mal Browser. Vergiss auch die Clients, die für Dich irgendeinen Nutzen haben könnten. Das sind nur _wenige_ der Clients, die mit einer solchen URL konfrontiert werden. _Verdammt_ wenige.

Cheatah

[Calocybe]

Moin!

Was meinst Du mit technisch illegal?

Aaaaaaah! Du hast gefragt! Jetzt haut Dir Cheatah wieder die alte RFC um die Ohren, in der steht, daß HTTP- und HTTPS-URLs weder Usernamen noch Password enthalten dürfen. Es funktioniert trotzdem in allen mir bekannten Browsern!

Browser vielleicht, aber das Web besteht nicht nur aus Browsern. Ich selbst habe schon Probleme gehabt, weil manche Proxies solche URLs eben nicht verstehen.

Und wenn Du sagst, das funktioniert in allen Dir bekannten Browsern, meinst Du da, es funktioniert, wenn Du so eine Adresse in die Location bar eingibst, oder hast Du wirklich mit all den Browsern probiert, wie sie reagieren, wenn so eine Adresse im Location-Header einer 302 Response steht? Das macht naemlich einen erheblichen Unterschied.

So long

[Cheatah]

Hi,

[...] wenn so eine Adresse im Location-Header einer 302 Response steht?

verkraftet der IE das eigentlich inzwischen?

Cheatah

[Calocybe]

Hi!

verkraftet der IE das eigentlich inzwischen?

Also beim besten Willen, das weiss ich nun wirklich nicht. ;-)

So long