weiterleitung bei 401

[Norbert]

Hallo,

habe eine eigene Fehlerseite fuer Error 401 definiert, aber die Browser (oder wer auch immer) ignorieren die Passworteingabe.
<?php
$target = 'http://www.google.de';
header('Location: '.$target);
?>

Wenn ich die Weiterleitung via <meta http-equiv=refresh
durchfuehre, wird die Login-Abfrage durchgefuehrt.

Kann mich da jemand bitte mal aufklaeren ...

Gruss und Dank
Norbert

[Cheatah]

Hi,

habe eine eigene Fehlerseite fuer Error 401 definiert, aber die Browser (oder wer auch immer) ignorieren die Passworteingabe.

natürlich. Eine Weiterleitung hat ja auch einen 3xx-Statuscode.

$target = 'http://www.google.de';

Und die hier zu findende Ressource dürfte 2xx sein.

Wenn ich die Weiterleitung via <meta http-equiv=refresh
durchfuehre, wird die Login-Abfrage durchgefuehrt.

Auf der Seite, die den <meta>-Tag beinhaltet und mit 401 ausgeliefert wird.

Kann mich da jemand bitte mal aufklaeren ...

Konsultiere diesbezüglich bitte Deine Eltern.

Cheatah

[Norbert]

Hi Cheatah,

wenn man was nicht versteht, warum auch immer, kann man das ruhig sagen, vielleicht habe ich mich ja unklar ausgedrueckt.

Also noch einmal:

habe eine eigene Fehlerseite fuer Error 401 definiert,
die Browser ignorieren die Passworteingabe.

d.h. die Error-401-Seite wird ausgefuehrt _bevor_ das Passwort abgefragt wird

Kann mich da jemand bitte mal aufklaeren ...
Konsultiere diesbezüglich bitte Deine Eltern.

oops,
mit Verbindungen ins Jenseits hatte ich noch nie Glueck ...

Gruss und Dank
Norbert

[Cheatah]

Hi,

wenn man was nicht versteht, warum auch immer, kann man das ruhig sagen,

ja, tu Dir keinen Zwang an.

d.h. die Error-401-Seite wird ausgefuehrt _bevor_ das Passwort abgefragt wird

Nein. Es gibt keine Seite, die mit einem Status 401 ausgeliefert wird.

Kann mich da jemand bitte mal aufklaeren ...
Konsultiere diesbezüglich bitte Deine Eltern.
mit Verbindungen ins Jenseits hatte ich noch nie Glueck ...

Die beste solche Verbindung nennt sich "Erinnerung".

Cheatah

[Norbert]

Hi Cheatah,

ja, tu Dir keinen Zwang an.

danke ... :-)

d.h. die Error-401-Seite wird ausgefuehrt _bevor_ das Passwort abgefragt wird
Nein. Es gibt keine Seite, die mit einem Status 401 ausgeliefert wird.

hmm,
warum erzaehlst Du das mir - erzaehls dem Apache ... ;-)

Demo:  http://www.topquality.de/ein.link.html
Wenn Du auf "zum Login" clickst kommt eine Passwortabfrage.
Falls Du das Passwort nicht weisst, oder auf abbrechen clickst,
wirst Du von einer 401-er-Seite mit Verzoegerung weitergeleitet.

Genau das wollte ich vereinfachen und statt dem
<meta http-equiv="refresh" ... usw. header(); verwenden,
was jedoch das Login abschaltet ... :-((

Gruss und Dank
Norbert

[Cheatah]

Hi,

Nein. Es gibt keine Seite, die mit einem Status 401 ausgeliefert wird.
warum erzaehlst Du das mir

weil Du für diesen Umstand verantwortlich bist.

erzaehls dem Apache ... ;-)

Apache verhält sich absolut richtig. Schaue doch mal in dessen Doku nach, was bei der ErrorDocument-Direktive zum Thema Status 401 schön fett gedruckt steht, und vergleiche das mit dem, was Du hier versuchst.

Cheatah

[Norbert]

Hi Cheatah,

wenn Du meine Frage nicht beantworten kannst/willst,
was ja offensichtlich der Fall ist, warum postest Du dann ueberhaupt ... <grmpf>

[Axel Richter]

Hallo,

wenn Du meine Frage nicht beantworten kannst/willst,
was ja offensichtlich der Fall ist, warum postest Du dann ueberhaupt ... <grmpf>

RTFM!

http://httpd.apache.org/docs-2.0/mod/core.html#errordocument
...
Wenn Sie eine entfernte URL in einer Anweisung ErrorDocument 401 verwenden, wird der Client darüber hinaus nicht wissen, dass er den Benutzer zur Eingabe eines Passwortes auffordern muss, da er den Statuscode 401 nicht erhält. Deshalb müssen Sie sich auf ein lokales Dokument beziehen, wenn Sie eine Anweisung ErrorDocument 401 verwenden.
...

viele Grüße

Axel

[Norbert]

Hallo Axel,

Wenn Sie eine entfernte URL in einer Anweisung ErrorDocument 401 verwenden ... f.f.

alles klar,
aber das war und ist nicht mein Problem !!

Noch einmal:
Das Errordokument tritt ja nur in Erscheinung, wenn das Login fehlschlaegt. Damit es fehlschlagen kann, muss die Abfrage erst mal erfolgen.

Danach wird das Errordokument ordentlich aufgerufen!
Es handelt sich hierbei um eine PHP-Seite.
Derzeit wird mit dem Errordokument ein <meta http-equiv ... u.s.w. ausgegeben.
Auch das funktioniert bestens !

Wenn ich jedoch den Meta-Tag im Errordokument gegen einen PHP-Befehl austausche, was IMHO die gleiche Funktionalitaet darstellt, erfolgt eine sofortige Weiterleitung _ohne_ Passwortabfrage.
Wohin weitergeleitet wird stand dabei nicht zur Debatte !

Gruss und Dank
Norbert

[Cheatah]

Hi,

aber das war und ist nicht mein Problem !!

doch, das war und ist es.

Das Errordokument tritt ja nur in Erscheinung, wenn das Login fehlschlaegt.

*Jeder* Response des Servers hat einen Statuscode. Die ErrorDocument-Direktive definiert gerade mal ein Verhalten dafür.

Damit es fehlschlagen kann, muss die Abfrage erst mal erfolgen.
Danach wird das Errordokument ordentlich aufgerufen!

Nein. Durch Dein Tun wird der falsche Statuscode ausgeliefert. Das Verhalten von Client und Server ist damit das, welches in der Apache-Doku bei der ErrorDocument-Direktive beschrieben wird.

Es handelt sich hierbei um eine PHP-Seite.

Das ist irrelevant. Der Status ist falsch, das ist das Problem.

Derzeit wird mit dem Errordokument ein <meta http-equiv ... u.s.w. ausgegeben.
Auch das funktioniert bestens !

Ja, weil jenes Dokument mit dem richtigen Status ausgeliefert wird.

Wenn ich jedoch den Meta-Tag im Errordokument gegen einen PHP-Befehl austausche, was IMHO die gleiche Funktionalitaet darstellt, erfolgt eine sofortige Weiterleitung _ohne_ Passwortabfrage.

YHO ist falsch. Ein Redirect hat einen anderen Statuscode als ein HTML-Dokument auf welchem irgend was passiert, was hier nicht von Belang ist.

Wohin weitergeleitet wird stand dabei nicht zur Debatte !

Da sind wir uns einig. Wo_her_ weitergeleitet wird ist jedoch hochgradig relevant.

Cheatah

[XaraX]

Hallo Axel,

aber das war und ist nicht mein Problem !!

Noch einmal:
Das Errordokument tritt ja nur in Erscheinung, wenn das Login fehlschlaegt. Damit es fehlschlagen kann, muss die Abfrage erst mal erfolgen.

Der Server antwortet mit 403 auf ein Fehlschlagen des Login. Du solltest also Dein PHP-Script mit dem header() als ErrorDocument für 403 einsetzen.

Wenn ich jedoch den Meta-Tag im Errordokument gegen einen PHP-Befehl austausche, was IMHO die gleiche Funktionalitaet darstellt, erfolgt eine sofortige Weiterleitung _ohne_ Passwortabfrage.
Wohin weitergeleitet wird stand dabei nicht zur Debatte !

Das ist soweit auch logisch. PHP überschreibt schlichtweg mit dem Location-Header den servereigenen Status 401 mit 302. vgl.: header() im Manual

"...Der zweite Spezialfall ist der "Location:" Header. Es wird nicht nur der Header an den Browser geschickt, sondern auch ein REDIRECT (302) Statuscode, wenn nicht bereits ein 3xx Statuscode gesendet wurde..."

Gruß aus Berlin!
eddi

[Axel Richter]

Hallo,

Der Server antwortet mit 403 auf ein Fehlschlagen des Login. Du solltest also Dein PHP-Script mit dem header() als ErrorDocument für 403 einsetzen.

Ja? Normalerweise kommt vom Server immer wieder ein 401, wenn die Anmeldung fehlschlägt.

viele Grüße

Axel

[XaraX]

Hallo Axel,

Der Server antwortet mit 403 auf ein Fehlschlagen des Login. Du solltest also Dein PHP-Script mit dem header() als ErrorDocument für 403 einsetzen.
Ja? Normalerweise kommt vom Server immer wieder ein 401, wenn die Anmeldung fehlschlägt.

Stimmt ^^

Gruß aus Berlin!
eddi

[Norbert]

Hallo,

nun mal der Reihe nach:
1. die eigentliche URL wird vom Browser an den Server gesendet
2. wegen der Auth-Direktive in der .htaccess schickt der Server einen 401-Header zurueck
3. der Browser fragt das Passwort ab und sendet es an den Server
4. die Seite wird ausgeliefert, falls das Passwort stimmt

Erst wenn das Passwort NICHT stimmt oder der User auf 'Abbrechen' clickt, kommt die Direktive fuer Error-401 ins Spiel, mit der man die Standardfehlerseite ueberschreibt.

Das klappt auch alles zur Zufriedenheit, solange man als Weiterleitung <meta http-equiv= ... verwendet.

Erst wenn man statt dessen header(); verwendet, geht alles in die Hose, sprich, das Passwort wird gar nicht erst abgefragt. Das ist definitiv der falsche Ablauf !

PS:
Die Idee statt einem 401-Doc ein 403-Doc zu definieren bringt nix.
Man erhaelt beim Abbruch oder falschem Passwort die Standardfehlerseite fuer Error-401.
Habe ich extra noch einmal getestet ... :-((

Gruss und Dank
Norbert

[Cheatah]

Hi,

nun mal der Reihe nach:

1. die eigentliche URL wird vom Browser an den Server gesendet
2. wegen der Auth-Direktive in der .htaccess schickt der Server einen 401-Header zurueck

[...]

Erst wenn man statt dessen header(); verwendet, geht alles in die Hose,

weilhierbeiderstatusnichtmehr401istsondernein3xxwasichdirschonganzamanfanggesagthabe.

Cheatah

[Henryk Plötz]

Moin,

nun mal der Reihe nach:

Vergiss bitte alles was du über HTTP Auth zu wissen glaubst. Es ist offensichtlich Unfug.

Das läuft so ab (Extremkrankheiten wie NTLM Auth jetzt mal ausgenommen):
1. Der Client sendet einen Request an den Server.
2. Der Server stellt fest, dass er den Request ohne Benutzerkennung nicht beantworten darf.
3. Der Server sendet eine Antwort an den Client die aus zwei Teilen besteht: Einem Header mit Statuscode 401 und weiteren Informationen zur gewünschten Authentisierung, sowie einem Body mit dem unter ErrorDocument 401 eingestellten Dokument (bzw. ggbf. einem Standardtext).
4. Der Client sieht den Status 401 und die weiteren Informationen, überlegt sich wie er sich dem Server gegenüber ausweisen kann und fragt ggbf. den User nach einem Passwort.
5. Der Client sendet einen Request an den Server der Authentisierungsdaten enthält.
6. Der Server findet die Authentisierungsdaten toll und liefert eine Antwort mit Status 200 und der eigentlich angefragten Ressource.

Der Knackpunkt ist Punkt 3: Wenn der Client keinen Status 401 sieht, fragt er natürlich auch nicht nach dem Passwort. An der Stelle hast du es kaputt gemacht: Durch ErrorDocument xxx http://... bewirkst du dass wann immer ein Statuscode xxx gesendet worden wäre stattdessen ein Redirect (Status dreihundertnochwas) auf den neuen URL gesendet wird. Das gilt ganz genau so bei 401: Dein Client kriegt nie einen 401 zu Gesicht, sondern nur den Redirect und führt ihn natürlich aus.

Erst wenn das Passwort NICHT stimmt oder der User auf 'Abbrechen' clickt, kommt die Direktive fuer Error-401 ins Spiel, mit der man die Standardfehlerseite ueberschreibt.

Nein. Das hat Cheatah aber schon länger versucht, dir mitzuteilen: Das Fehlerdokument für 401 wird immer bei Status 401 mitgesendet. Der Server kann ja schliesslich nicht wissen ob der User auf Abbrechen gedrückt hat oder das Passwort nicht stimmt oder ob der Client überhaupt weiss wie man mit HTTP Auth umzugehen hat.

PS:
Die Idee statt einem 401-Doc ein 403-Doc zu definieren bringt nix.
Man erhaelt beim Abbruch oder falschem Passwort die Standardfehlerseite fuer Error-401.

Ja, das ist auch Unsinn. 403 hat nichtmal ansatzweise was mit HTTP Auth zu tun. (Der Fehler wird in Selfhtml 8.1 auch korrigiert sein.)

[Norbert]

Hallo Henryk,

nun mal der Reihe nach:
Vergiss bitte alles was du über HTTP Auth zu wissen glaubst.

okay,
wenn der Server das 401-Doc _sofort_ mitsendet, ist das Verhalten einfach nachvollziehbar.

Diese Tatsache war mir leider wirklich unbekannt und fuer mich aus _keinem_ der bisherigen Postings ersichtlich.

Auch wusste ich nicht, dass in diesem Forum neuerdings beleidigende Ausfaelle gegenueber einem Fragesteller zum "guten Ton" gehoeren.
Man wird sich einfach anpassen muessen, leider ... :-((

Trotzdem vielen Dank fuer die Information
(bitte nicht aufregen,

• ich gewoehne es mir sicher bald ab)

[Vinzenz]

Hallo Norbert,

Auch wusste ich nicht, dass in diesem Forum neuerdings beleidigende Ausfaelle gegenueber einem Fragesteller zum "guten Ton" gehoeren.

Ausfälle gehören nicht zum guten Ton,
gehörten nie zum guten Ton,
werden nie zum guten Ton gehören.

Man wird sich einfach anpassen muessen, leider ... :-((

Wer hat hier mit Ausfällen angefangen? Wer ist als Einziger ausfallend geworden?
Lies bitte den Thread noch einmal von Anfang bis Ende durch. Und antworte dann.

Freundliche Grüsse,

Vinzenz

[Norbert]

Hi Vinzenz,

Lies bitte den Thread noch einmal von Anfang bis Ende durch.
Und antworte dann.

sorry,
da komme ich immer nur bis zur ersten Antwort von Ceatah, und schon ist mein Blutdruck auf 220.
Ich empfinde das auch noch viele Stunden spaeter als bodenlose Unverschaemtheit.

Meine Enkel sagen mir zwar auch, dass es zwecklos waere sich darueber aufzuregen, aber wer kann schon gegen seine Natur ?

Gute Nacht
Norbert

[Axel Richter]

Hallo,

da komme ich immer nur bis zur ersten Antwort von Ceatah, und schon ist mein Blutdruck auf 220.
Ich empfinde das auch noch viele Stunden spaeter als bodenlose Unverschaemtheit.

Du meinst damit den Hinweis auf die Zuständigkeit Deiner Eltern für Deine Aufklärung? Wenn ja, dann ist Dein Humordetektor defekt.

viele Grüße

Axel

[Rudolph]

Hallo,

gemeinhin wird der Komiker ausgewechselt und nicht das Publikum, wenn Witze nicht ankommen !
Und im Informatik-Studium lehrt man, dass der Sender solange geändert werden muss, bis der Empfänger wie gewünscht reagiert.
Zumindestens letzteres sollte PHP-lern bekannt sein.

Es handelt sich hier also um einen klassischen Doppelfehler:
Unverstaendliche Erklaerung/Hilfe gepart mit unpassendem Gag.

Jede Rohheit hat ihren Ursprung in einer Schwäche.
Lucius Annaeus Seneca (ca. 4 v. Chr - 65 n. Chr.),

Schönen Sonntag noch
Rudolph

[wahsaga]

hi,

gemeinhin wird der Komiker ausgewechselt und nicht das Publikum, wenn Witze nicht ankommen !

gemeinhin kann das publikum sich auch eine andere örtlichkeit zum abhängen suchen, wenn ihm der humor des komikers nicht passt.

das recht, sein geld zurück zu verlangen, hat es darüber hinaus nur dann, wenn überhaupt eintritt bezahlt wurde.
hier hingegen hat es lediglich das recht, auf applaus zu verzichten, wenn ihm nicht danach ist.

gruß,
wahsaga

[Axel Richter]

Hallo,

gemeinhin wird der Komiker ausgewechselt und nicht das Publikum, wenn Witze nicht ankommen !

Ja, aber Cheatah tritt hier nicht gegen Honorar auf.

Und im Informatik-Studium lehrt man, dass der Sender solange geändert werden muss, bis der Empfänger wie gewünscht reagiert.

Wah? Welcher Kursteil ist das? Was ist Sender und Empfänger? Meinst Du Client und Server? Normalerweise sind Client und Server ausreichend spezifiziert und die Spezifikationen hinreichend bekannt, um dem Programmierer eine exakte Information darüber zu geben, was der Client bzw. der Server erwartet, um wie gewünscht zu reagieren. Das nennt sich Protokoll. Try and Error ist wohl eher was für Hacker.

Es handelt sich hier also um einen klassischen Doppelfehler:
Unverstaendliche Erklaerung/Hilfe gepart mit unpassendem Gag.

Nein, das sehe ich anders. Ich lese das Ursprungsposting und erwarte einen Programmierer, der weiß, was HTTP, HTTP Response Status Codes und HTTP Authentication sind und wie sie funktionieren, der nur eine Verständnisschwierigkeit mit 401 vs. 301 hat und der weiß, wo er nachzusehen hat, wenn man ihn dezent darauf hinweist. Das ist, meiner Meinung nach, in Cheatahs Posting geschehen.

Jede Rohheit hat ihren Ursprung in einer Schwäche.
Lucius Annaeus Seneca (ca. 4 v. Chr - 65 n. Chr.),

Ja, hier in der Schwäche mit Dokumentationen umzugehen.

btw.: Wenn Du den harmlosen Scherz als Rohheit siehst, hast Du wirkliche Rohheit noch nicht erlebt.

viele Grüße

Axel

[Rudolph]

Hallo,

btw.: Wenn Du den harmlosen Scherz als Rohheit siehst,
hast Du wirkliche Rohheit noch nicht erlebt.

hmm,
es geht nicht darum, wie Du, ich oder Cheatah das sehen.
Entscheidend ist _nur_ wie es ankommt, nur _das_ zaehlt.
Wobei es absolut unabhängig von unserer Meinung ist,
nur die Wirkung beim Empfaenger zaehlt !

Meistens liegt an der Tagesform, wann man grinst oder brüllt.
Es ist wie inner Disco, fuer den gleichen Scherz kann man
eine gescheuert bekommen oder zu Boden geknuscht werden.
Das muss nicht unbedingt am Gag liegen.

Fröhliche Woche
Rudolph

[Mathias Bigge]

Hi Rudolph,

Und im Informatik-Studium lehrt man, dass der Sender solange geändert werden muss, bis der Empfänger wie gewünscht reagiert.

Gibt es dort auch Informatikerwitze? Die so lange geändert werden, bis einer lacht?

Zumindestens letzteres sollte PHP-lern bekannt sein.

Die PHP-Humorseite *g*

Jede Rohheit hat ihren Ursprung in einer Schwäche.
Lucius Annaeus Seneca (ca. 4 v. Chr - 65 n. Chr.),

Cheatahs Schwächen liegen ja offen zu Tage, ebenso seine Phobien. Insofern hast Du völlig Recht.

Einige Beispiele für Informatikerhumor gibt es erschreckenderweise hier:
http://www.gravenreuth.de/infor.html

Viele Grüße
Mathias Bigge

[mapo]

Hi,

Einige Beispiele für Informatikerhumor gibt es erschreckenderweise hier:
http://www.gravenreuth.de/infor.html

Darauf nen Link zu setzen zeugt wirklich von Humor ;-)

Gruß
Manfred

[Mathias Bigge]

Hi mapo,

Einige Beispiele für Informatikerhumor gibt es erschreckenderweise hier:
http://www.gravenreuth.de/infor.html
Darauf nen Link zu setzen zeugt wirklich von Humor ;-)

Sorry, manchmal bin ich einfach bösartig.....

Viele Grüße
Mathias Bigge

[Axel Richter]

Hallo,

wenn der Server das 401-Doc _sofort_ mitsendet, ist das Verhalten einfach nachvollziehbar.
Diese Tatsache war mir leider wirklich unbekannt und fuer mich aus _keinem_ der bisherigen Postings ersichtlich.

Aus der Aussage im Apache-Manual geht das aber hervor. Du hattest bisher auch nicht angedeutet, wie Du HTTP-Authentication verstanden hast.

Um Unklarheiten zu beseitigen, sollte man sich die entsprechenden Spezifikationen nochmals ansehen.

http://www.w3.org/Protocols/rfc2616/rfc2616.html
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2

http://www.ietf.org/rfc/rfc2617.txt

Beachte, dass der Response "401 Unauthorized" heißt und nicht "Authentication denied". Letzteres würde mit dem verbindungslosen HTTP auch gar nicht funktionieren. Der Server weiß nämlich, wenn er einen Request mit einem Authorization request-header field bekommt, gar nicht, ob er vorher mit einem 401 geantwortet hat. Zwischen dieser möglichen Antwort und dem Request mit Authorization request-header field können tausende andere Requests liegen. Er prüft einfach, wenn die angeforderte Ressource es erfordert, weil sie geschützt ist, ob es überhaupt ein Authorization request-header field gibt und wenn ja, ob die darin gelieferten Daten mit den gespeicherten notwendigen Daten zur Authentifizierung übereinstimmen. Wenn beides ja, wird die Ressource ausgeliefert, wenn eines nein, gibt es wieder ein 401 Unauthorized.

viele Grüße

Axel

[Sven Rautenberg]

Moin!

nun mal der Reihe nach:

1. die eigentliche URL wird vom Browser an den Server gesendet
2. wegen der Auth-Direktive in der .htaccess schickt der Server einen 401-Header zurueck
3. der Browser fragt das Passwort ab und sendet es an den Server
4. die Seite wird ausgeliefert, falls das Passwort stimmt

Erst wenn das Passwort NICHT stimmt oder der User auf 'Abbrechen' clickt, kommt die Direktive fuer Error-401 ins Spiel, mit der man die Standardfehlerseite ueberschreibt.

Nein.

1. Der Browser ruft die Seite vom Server ab.
2. Der Server antwortet mit Status 401, schickt dabei auch gleich die Fehlerseite mit.
3. Der Browser kriegt den 401 und öffnet ein Eingabefenster.
3a. Wenn der User hier Abbrechen klickt, wird die soeben gesendete Fehlerseite angezeigt.
3b. Wenn der User ein Passwort eingibt, fordert der Browser die Seite vom Server NOCHMAL ab.
4. Wenn das Passwort stimmt, kommt jetzt die tatsächliche Seite, andernfalls springe zu 2. (kein Passwort == falsches Passwort)

Ein "ErrorDocument 401" verändert also die Seite, die man sieht, wenn man auf Abbrechen klickt.

Wenn du aber dieses ErrorDocument in ein Redirect wandelst, antwortet der Server schon in Punkt 2 nicht mit einem 401, sondern mit einem 301 oder 302 und liefert die Weiterleitung mit. Der Browser fragt also nicht nach dem Passwort, weil er keinen Status 401 kriegt, sondern er geht direkt zur neuen Location der Weiterleitung.

Deshalb unterm Strich: Man KANN Status 401 + Meta-Refresh NICHT durch eine HTTP-Weiterleitung für Status 401 ersetzen. PUNKT.

Erst wenn man statt dessen header(); verwendet, geht alles in die Hose, sprich, das Passwort wird gar nicht erst abgefragt. Das ist definitiv der falsche Ablauf !

Weil du dir nicht klarmachst (und das versucht Cheatah dir schon seit der ersten Minute zu verdeutlichen), was tatsächlich passiert. Das Klicken auf "Abbrechen" im Passwortdialog hat keine weitere Serverkommunikation zur Folge, sondern bewirkt lediglich das Anzeigen der Fehlerseite "Authentifizierung fehlgeschlagen" (diese kann mit ErrorDocument "schön" gemacht worden sein - solange das kein Redirect ist, ist alles bestens).

• Sven Rautenberg

[Cheatah]

Hi,

wenn Du meine Frage nicht beantworten kannst/willst,
was ja offensichtlich der Fall ist,

wenn Du es nötig hast, bei Problemen mit Zaunpfählen geprügelt zu werden, kann ich Dir in der Tat nicht helfen, nein. Aber bitte behaupte deshalb nicht, ich könne oder wolle Deine Frage nicht beantworten. An Deiner Unfähigkeit, Informationen nachzulesen und aufzunehmen bin ich schließlich nicht schuld.

Cheatah

[wahsaga]

hi,

wenn Du meine Frage nicht beantworten kannst/willst,
was ja offensichtlich der Fall ist, warum postest Du dann ueberhaupt ... <grmpf>

selber <grmpf>

wenn du nicht in der lage bist, die zusammenhänge zu verstehen - dann denke doch wenigstens noch mal eingehender über sie nach, wenn man dich darauf hinweist.

gruß,
wahsaga