Nicht noch eine Benutzerverwaltungsfrage!

[Uschi Renziehausen]

Hallo Christian, hallo Michael,

Ich muß mal ein paar Fragen fragen, büdde :-))

Nein, PHP transportiert die Session-Informationen in der URL *oder* im Cookie, je nachdem, was der Benutzer versteht.

Gehe ich recht in der Annahme, dass zunächst ausprobiert wird, ob der User Cookies zuläßt und dann kommt die URL an die Reihe?

Das funktioniert so: beim session_start wird erst mal das Cookie gesetzt.

Wohin wird dieses Cookie gesetzt? Beim Client, oder? Und wenn der keine Cookies zulässt, wird auch keins gesetzt, geht ja nicht. Wäre die korrekte Formulierung: "Bei session_start() wird versucht, ein Cookie zu setzen"?

Falls in den Cookies keine Session-ID nicht auftaucht, wird davon ausgegangen, dass der User keine Cookies mag. Dann werden URLs automatisch umgeschrieben. (sofern url-rewriting aktiviert ist).

Heisst das, PHP guckt in dem superglobalen Array $_COOKIE nach, ob in $_COOKIE["PHPSESSID"] oder wie immer der Name für die SessionID auch lautet, mit einem brauchbaren Wert versehen ist?

Wenn der Benutzer Cookies akzeptiert, dann wird die URL halt nur beim ersten Mal umgeschrieben, beim zweiten mal nicht. Ich persönlich schalte URL-Reweriting aber lieber per ini_set vor session_start aus, da ich den Server nicht unnötig belasten will.

Die Schreibarbeit bei den Links lohnt sich, denn wenn PHP jedesmal vor der Auslieferung die Seite parsen muss, kostet das wirklich Rechenpower und Zeit. Vor allem aber ersetzt das URL-Rewriting AFAIK nicht so sonderfälle wie Location-Header o.ä.
Der vorstehende Absatz ist mir ein Buch mit sieben Giebeln:

1. Wenn du via ini_set das URL_Rewriting abschaltest, muss dein User Cookies erlauben, oder die gesamte Autentifizierung funktioniert überhaupt nicht. Richtig oder falsch?

2. Meinst du mit Schreibarbeit bei den Links, dass du bei den Links, wo du mit Session-Variablen arbeitest, diese in dem Fall, dass der User cookies nicht erlaubt, halbautomatisch anhängst.
   Also in etwa so:
   $url = "/link/auf/eine/interne/datei.php";
   if(!$COOKIE["PHPSESSID"]) {
     $url .= "?id=" .session_id();
   }

Und wenns nach draussen geht, dann läßt du die sessionID eben weg? Und ebenfalls dann, wenn der Link auf eine interne Seite (.php) geht, bei der keine Sessions benötigt werden?

Zum Referer-Problem:

Gehe ich recht in der Annahme, daß das Referer-Problem darin besteht, daß im Falle eines automatischen URL-rewritings durch PHP die session_id auch an eine fremde URL weitergeben würde?

GMX zum Beispiel schaltet noch eine Seite davor, bevor man auf einen Link klickt, damit gerade so etwas vermieden wird. Dass das aber auch Nachteile im Bereich Datenschutz hat, ist klar. Vielleicht wäre es eine Lösung, die Seite nur davorzuschalten, wenn im _aktuellen_ Query-String des Scripts, das den Link ausgibt, die Session-ID vorkommt - und wenn sie nicht vorkommt, dann ist der Referer auch kein Problem.

Ich habe noch nie verstanden, warum GMX diese nervige Seite dazwischen hat. Nun weiß ich, es hat mit sessions zu tun, aber verstanden habe ich es nicht :-(((

Liebe Grüße, Uschi
(PS: mit den header-geschichten habe ich mich bislang gar nicht auseinandergesetzt. ich schätze, ich sollte das mal tun?)