nicht angemeldet
htaccess-user abfragen??
hallo,
ich möchte auf einer website den eingeloggten user abfrage.
eigentlich geht das mit $_SERVER['PHP_AUTH_USER'].
nun mein problem: ich möchte auf einer einzelnen seite, die nicht im passwortgeschützten, also im frei zugänglichen bereich liegt,
eine if-bedingung einbauen, sodass zw. eingeloggten und nicht eingeloogten usern eine unterschiedliche darstellung kommt. $_SERVER['PHP_AUTH_USER'] funktioniert aber nur, wenn die seite auch tatsächlich über htaccess geschützt ist. gibt es eine andere variable, die ich da abfragen kann? oder wirds da komplizierter?
danke und lg
p
-
gibt es eine andere variable, die ich da abfragen kann? oder wirds da komplizierter?
Setze beim einloggen ein Cookie. Das kannst du dann bereits in htaccess abfragen oder halt irgendwo im Gültigkeitsbereich des Cookies.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische -
Hallo Paul,
nun mein problem: ich möchte auf einer einzelnen seite, die nicht im passwortgeschützten, also im frei zugänglichen bereich liegt,
eine if-bedingung einbauen, sodass zw. eingeloggten und nicht eingeloogten usern eine unterschiedliche darstellung kommt. $_SERVER['PHP_AUTH_USER'] funktioniert aber nur, wenn die seite auch tatsächlich über htaccess geschützt ist. gibt es eine andere variable, die ich da abfragen kann? oder wirds da komplizierter?es liegt in der Natur der HTTP-Authentifizierung, Nutzerkennungen nur in passwortgeschützten Bereichen zu erwarten und dem entsprechen auch nur dort zu senden. Du könntest aber den Nutzer mit einem Cookie wiedererkennen, der einen größeren Bereich als den passwortgeschützten abdeckt. Diesen Cookie könntest Du nach erfolgreichem login an die Nutzer emitieren. Als Wert kannst Du in ihm den Nutzernamen ablegen und auf den gewünschten Ressourcen außerhalb des passwortgeschützten Bereiches z. B. mittels $_COOKIE darauf zugreifen. Jedoch können Cookies vom Nutzer auch deaktiviert werden, was Du bei Ausgaben an den Nutzer ebenso bedenken solltest.
Gruß aus Berlin!
eddi-
Hallo,
es liegt in der Natur der HTTP-Authentifizierung, Nutzerkennungen nur in passwortgeschützten Bereichen zu erwarten und dem entsprechen auch nur dort zu senden. Du könntest aber den Nutzer mit einem Cookie wiedererkennen, der einen größeren Bereich als den passwortgeschützten abdeckt. Diesen Cookie könntest Du nach erfolgreichem login an die Nutzer emitieren. Als Wert kannst Du in ihm den Nutzernamen ablegen und auf den gewünschten Ressourcen außerhalb des passwortgeschützten Bereiches z. B. mittels $_COOKIE darauf zugreifen. Jedoch können Cookies vom Nutzer auch deaktiviert werden, was Du bei Ausgaben an den Nutzer ebenso bedenken solltest.
Würde es nicht $_SESSION bzw. session_start() auch bringen? Das versucht sich ja frei von Cookies zu machen.
Gruß
jobo
-
Hallo Jobo,
Würde es nicht $_SESSION bzw. session_start() auch bringen?
klar.
Das versucht sich ja frei von Cookies zu machen.
Wenn man wie folgt derart von den Defaults abweicht, ja:
ini_set('session.use_cookies', 0); ini_set('session.use_only_cookies',0); ini_set('session.use_trans_sid', 1);Gruß aus Berlin!
eddi-
Hallo,
Würde es nicht $_SESSION bzw. session_start() auch bringen?
klar.
Das versucht sich ja frei von Cookies zu machen.
Wenn man wie folgt derart von den Defaults abweicht, ja:
ini_set('session.use_cookies', 0);
ini_set('session.use_only_cookies',0);
ini_set('session.use_trans_sid', 1);Nicht zwingen. Man spart sich den Test, ob der Client Cookies akzeptiert, denn das macht die Session automatisch und reagiert entsprechend, wenn der Client das nicht tut, dachte ich. Gruß jobo-
Re:
Das versucht sich ja frei von Cookies zu machen.
Wenn man wie folgt derart von den Defaults abweicht, ja:
ini_set('session.use_cookies', 0);
ini_set('session.use_only_cookies',0);
ini_set('session.use_trans_sid', 1);> > Nicht zwingen. Nach Deiner Aussage, dass Session versuchen, sich frei von Cookies zu machen, steht die Konfiguration mit defaults dem entgegen. (vgl. [session.use_only_cookie](http://de2.php.net/manual/de/session.configuration.php#ini.session.use-only-cookies), [session.use_trans_sid](http://de2.php.net/manual/de/session.configuration.php#ini.session.use-trans-sid)) > Man spart sich den Test, ob der Client Cookies akzeptiert, denn das macht die Session automatisch und reagiert entsprechend, wenn der Client das nicht tut, dachte ich. Soweit wir beide vom üblichen [Session-Modul](http://de2.php.net/manual/de/book.session.php) PHPs reden, verstehe ich Deine Aussage nicht. Es finden kein Test statt. Entweder es werden Sitzungsdaten vom Client übertragen, dann wird die Kennung dieser beibehalten, andernfalls wird mit jeder weiteren sitzungsrelevanten Anfrage eine neue Kennung erstellt und dem Client zugesandt. Gruß aus Berlin! eddi-
Hallo,
Soweit wir beide vom üblichen Session-Modul PHPs reden, verstehe ich Deine Aussage nicht. Es finden kein Test statt. Entweder es werden Sitzungsdaten vom Client übertragen, dann wird die Kennung dieser beibehalten, andernfalls wird mit jeder weiteren sitzungsrelevanten Anfrage eine neue Kennung erstellt und dem Client zugesandt.
Ja, ich dachte, session_start() würde auf Cookies testen und dann ggfs versuchen, die Session-Id als Post oder als Get-Variable zu übermitteln
"example.com?sessionid=134^qeqwe3rt12341234" zB.
Gruß
jobo
-
Hi,
Ja, ich dachte, session_start() würde auf Cookies testen und dann ggfs versuchen, die Session-Id als Post oder als Get-Variable zu übermitteln
Beim ersten, eigentlichen *Start* der Session versucht PHP einen Cookie zu setzen, *und* gibt die Session-ID per GET/POST weiter (sofern ihm das erlaubt wurde), durch Umschreiben von Linkzielen und Erweiterung von Formularen um ein verstecktes Feld.
Erst bei der nächsten Wiederaufnahme der Session erlaubt sich PHP aus der Tatsache, dass die SID vom Client per Cookie zurückübermittelt wurde, den Schluss, dass dies auch für den weiteren Verlauf der Session mit diesem Client funktionieren wird, und stellt die Übergabe per GET/POST ein.
Wenn kein Cookie mit dem Request mitgeschickt wurde, dann geht es wieder wie oben weiter.MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
-
-
-
-
-
Würde es nicht $_SESSION bzw. session_start() auch bringen? Das versucht sich ja frei von Cookies zu machen.
Du redest von der Tatsache, dass PHP SIDs auch via Content transportieren kann, wenn man es so konfiguriert.
Ich bin nicht mal so überzeugt, ob der SID-Transport über Links eine so gute Sache ist.
Was würde geschehen, wenn Google kein Cookie senden würde? Alle schönen SEO Links werden durch sids verunstaltet. Ungültige sids landen in Bookmarks. etc...Es gibt eine pragmatische Haltung: Wer kein Cookie sendet, will als User keine Session, und muss damit jene Benutzerführung akzeptieren, die dieser Status erlaubt.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Was würde geschehen, wenn Google kein Cookie senden würde? Alle schönen SEO Links werden durch sids verunstaltet. Ungültige sids landen in Bookmarks.
Hinsichtlich der Problembeschreibung des OP ist dieser Einwand Unsinn. Die Session würde nur vergeben werden, wenn der Nutzer sich vorher authentifiziert hat. Das hat also nichts mit SEO zu tun und was so ungeheuerlich an ungültigen SIDs in Lesezeichen sein soll, sehe ich im Übrigen auch nicht.
etc...
Das führe bitte aus!
Gruß aus Berlin!
eddi-
Was würde geschehen, wenn Google kein Cookie senden würde? Alle schönen SEO Links werden durch sids verunstaltet. Ungültige sids landen in Bookmarks.
Hinsichtlich der Problembeschreibung des OP ist dieser Einwand Unsinn.
Da gebe ich dir recht. Aber Im Falle von SIDs via Link ist doch die Continuität nicht gegeben.
Source 1 erstellt SID
Source 2 über php, bestätigt sie
Source 3 uups statische Seite, Sid weg
Source 4 wieder über php keine Sid mehrDie Session würde nur vergeben werden, wenn der Nutzer sich vorher authentifiziert hat. Das hat also nichts mit SEO zu tun und was so ungeheuerlich an ungültigen SIDs in Lesezeichen sein soll, sehe ich im Übrigen auch nicht.
Och. Ich bin genug genarrt worden von Links, die mir dann 404 Seite gezeigt haben. Gut das kann dir bei einem Cookie auch geschehen.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Re:
Im Falle von SIDs via Link ist doch die Continuität nicht gegeben.
Das ist tatsächlich ein Problem. Das gesamte Web müsste dem Rechnung tragen und alle Dokumente dynamisch generieren. Da ist dann ein Keks das kleinere Übel.
Ich bin genug genarrt worden von Links, die mir dann 404 Seite gezeigt haben.
Man mag es kaum glaube, dass ausgerechnet Du Dich davon beirren lässt. Ich sah beim Web eines Schweizers nur 403... :-P
Och.
Aber ich sehe gerade, meinem Individualismus wegen des User-Agent-Header wurde Generalamnestie zuteil.
Gruß aus Berlin!
eddi
-
-
-
-
-