nicht angemeldet
Sessionverwaltung und Authentifikation
Hallo,
nachdem wir uns nun zwei Tage zu Dritt mit den Sessions in PHP, aber vor allem mit den schlechten und teilweise widersprüchlichen Dokumentationen rumgeschlagen haben, haben wir einigermaßen Überblick erhalten. Wir sind nun dabei, eine eigene Doku zu erstellen, damit die teilweise leider nur empirisch ermittelten Zusammenhänge nicht wieder versickern. Ich habe gerade das Inhaltsverzeichnis geschrieben und bin auf mehr als 30 Überschriften ersten Grades gekommen. Es dürften also so ca. 100 bis 150 Seiten werden.
Wir haben nur mit den PHP-Grundfunktionen gearbeitet, also ohne die OOP-Lib. Außerdem haben wir uns ein paaar Hilfsmittel (Monitor-Programme) erstellt.
Einige Fragen bestehen aber noch, und die würde ich gerne mit Euch zusammen klären:
1.) Es gibt scheinbar Unterschiede zwischen einem "Session-Cookie" und einem "normalen" Cookie. Wie bilden die sich in der System-Programmierung oder im HTTP-Protokoll ab?
2.) Wie kann ich einen solchen Session-Cookie auf der Workstation feststellen und auslesen? Gibt es Tools?
3.) Welche offiziellen Möglichkeiten gibt es festzustellen, ob eine Session besteht? Wir haben nur die Auswerung der Konstante SID finden können.
4.) Gibt es eine Möglichkeit, ein session_register() direkt auf einzelen der $HTTP_POST_VARS auzuüben?
Das sind die ersten Fragen. Die nächsten ergeben sich bestimmt beim Schreiben der Doku.
Wenn Ihr noch Anregugnen habt, was man da mit aufnehmen sollte, dann freuen wir uns über Rückmeldung; wenn der Thread vorbei ist an mailto:doku@bitworks.de
Liebe Grüße aus http://www.braunschweig.de
Tom
-
Hallo,
1.) Es gibt scheinbar Unterschiede zwischen einem "Session-Cookie" und einem "normalen" Cookie. Wie bilden die sich in der System-Programmierung oder im HTTP-Protokoll ab?
Ein Session-Cookie dient nur zur Identifizierung der Session (pseudo Zustand) und ist ein stink normales Cookie nur mit dem Unterschied, das es automatisch gehändelt wird. Es ist nicht das serverseitige Session-Objekt. Dieses wird mit jeder _neuen_ Sitzung erzeugt und steht nur serverseitig zur Verfügung, sprich die Daten kommen nicht in das Session-Cookie. Wie es um die Besitzverhältnisse des Session-Cookies steht weiß ich leider nicht, sprich ob es clientseitig manipuliert werden kann un inwiefern es sich auf die Session auswirken würde. Fakt ist, dass wenn der Client keine Cookies zulässt, es zu keiner Sitzung kommt.
3.) Welche offiziellen Möglichkeiten gibt es festzustellen, ob eine Session besteht? Wir haben nur die Auswerung der Konstante SID finden können.
HTTP ist zustandslos, daher auch die Sache mit dem Session-Cookie, um selbige (Session) als solche zu identifizieren bzw. eine Art Pseudo-Zustand zu beschreiben*. Beide verfallen nach einer festgelegten Zeit. Gesichert ist nur, dass innerhalb dieser Zeit eine Sitzung (weiter)bestehen _kann_, sprich der Web-Server hält sich die Optionen offen (Session, SID) eine Sitzung weiter am Leben zu erhalten, ungeachtet der Tatsache ob diese nun _wirklich_ noch besteht (Client). Es ist also letztendlich auf Protokollebenen nicht möglich die Exsistenz einer Session festzulegen, sondern nur diese zu beschreiben/erklären.
Anders wäre es mit Komponenten, welche den Sitzungszustand über eine client-/serverseitige Kommunikation sichern (nicht wirklich, da HTTP). Dies kann aber mit Cookies nicht erreicht werden, denn diese stellen nur einen Datenhalter/-container dar, keine Komponente.hth
ralfPS: ich komme nicht aus der PHP-Ecke, schätze aber, dass es dort nicht
anders ablaufen wird/kann.*) einseitiger (serverseitiger) Zustand, da der Client nur das Cookie
an sich bereitstellt (nicht gesicherter Zustand, Cookie und HTTP)-
Hallo Ralf,
danke für Deine Antwort. Eine ist bersser als gar keine. *freu*
Die Antwortflut[tm] zeigt mir aber, dass wohl KEINER wirklich Ahnung von der Materie hat. Umso mehr ein Grund, hier weiter zu forschen und zu dokumentieren.
Bleibt die Frage, wo find ich den?
Zu 1)
Wir haben in unseren Versuchen Session-Cookies erzeugt. Diese wurden allerdings im Cache des MSIE 5.5 nicht angezeigt, während "normale" Cookies immer zur Anzeige kamen. Meine Frage zeielte also darauf ab, ob es wohl in der Spezifikation für das Cookie ein Flag gibt, dass besagt: bitte nur im Hauptspeicher, nicht auf Festplatte.Außerdem konnte ich auch keine Cache-Einträge für die mit session-start() geöffneten Seiten feststellen.
Liegt das nun am MSIE oder ist das Standard (mit "d")?
zu 3.)
Es geht hier ausschließlich um die Scriptverarbeitung auf dem Server. Es soll "lediglich" festgestellt werden, ob für das Script eine gültige Session vorhanden ist oder nicht, allerdings OHNE eine neue Session zu starten, wenn noch keine vorhanden ist.Wir haben hier eben nur das Auslesen der Konstante SID ermitteln können, die immer nur dann einen Wert enthält, wenn die Session für dieses Script NEU GESTARTET worden ist.
Neue Frage:
5.) Wir haben das Verzeichnis session.save_path in ein eigenes Session-Verzeichnis verlegt. Außerdem habe ich mir die Freiheit genommen, die Rechte für das Verzeichnis auf "d -wx --- ---" zu setzen. Eigentüner des Verzeichnisses ist der wwwrun. Die Sessions laufen einwandfrei mit dieser Einstellung.Wie kann ich nun qualifiziert herausfinden, ob der Garbage-Collector von dieser Einstellung betroffen ist? Kennt jemand die Stelle im Sourcecode? Arbeitet PHP intern mit einem Session-Table, oder muss der GC das Verzeichnis brwosen dürfen?
Ich hoffe, dass es doch noch jemand gibt, der das Eine oder Andere beitragen kann. Ich möchte in meine Doku keinen Scheiss reinschreiben...
Liebe Grüße
Tom
-
Hallo!
Die Antwortflut[tm] zeigt mir aber, dass wohl KEINER wirklich Ahnung von der Materie hat. Umso mehr ein Grund, hier weiter zu forschen und zu dokumentieren.
das kann man so sehen, muß man aber nicht ;-)
Bleibt die Frage, wo find ich den?
wen?
Zu 1)
Wir haben in unseren Versuchen Session-Cookies erzeugt. Diese wurden allerdings im Cache des MSIE 5.5 nicht angezeigt, während "normale" Cookies immer zur Anzeige kamen. Meine Frage zeielte also darauf ab, ob es wohl in der Spezifikation für das Cookie ein Flag gibt, dass besagt: bitte nur im Hauptspeicher, nicht auf Festplatte.Wie gesagt, das ist HTTP, das kann man nachlesen. Wie auch immer.
Außerdem konnte ich auch keine Cache-Einträge für die mit session-start() geöffneten Seiten feststellen.
weil es nunmal Session_cookies sind. Was würden die für einen Sinn machen wenn die auf der Platte blieben???
zu 3.)
Es geht hier ausschließlich um die Scriptverarbeitung auf dem Server. Es soll "lediglich" festgestellt werden, ob für das Script eine gültige Session vorhanden ist oder nicht, allerdings OHNE eine neue Session zu starten, wenn noch keine vorhanden ist.In den von mir geposteten Links steht auch wo die Sessions serverseitig gespeichert werden...
Aber ich versteh nicht was Dir das alles bringt. Der Sessionmechanismus von PHP ist hervorragend und einfach, was willst Du da groß eingreifen? Sicherer bekommst Du Deine Scripte dadurch nicht, vermutlich baust Du eher eigene Sicheheitslücken ein!Wir haben hier eben nur das Auslesen der Konstante SID ermitteln können, die immer nur dann einen Wert enthält, wenn die Session für dieses Script NEU GESTARTET worden ist.
was ist das Problem?
Neue Frage:
5.) Wir haben das Verzeichnis session.save_path in ein eigenes Session-Verzeichnis verlegt. Außerdem habe ich mir die Freiheit genommen, die Rechte für das Verzeichnis auf "d -wx --- ---" zu setzen. Eigentüner des Verzeichnisses ist der wwwrun. Die Sessions laufen einwandfrei mit dieser Einstellung.Wie kann ich nun qualifiziert herausfinden, ob der Garbage-Collector von dieser Einstellung betroffen ist? Kennt jemand die Stelle im Sourcecode? Arbeitet PHP intern mit einem Session-Table, oder muss der GC das Verzeichnis brwosen dürfen?
http://www.php-faq.de/q-sessions-dateisystem.html Dann kannst Du einiges in der php.ini vrändern, und manche Sachen kann man auch einfach mal selbst testen!
Verrätst Du mir warum Du das alles machen möchtest? Das kann man alles irgendwo nachlesen, wo weiß ich jetzt nicht und es interessiert mich auch nicht.
Wenn Du volle Kontrolle über die Session haben willst, schreibe Dir einen eigenen Session-Mechanismus oder benutze PERL.Ich hoffe, dass es doch noch jemand gibt, der das Eine oder Andere beitragen kann. Ich möchte in meine Doku keinen Scheiss reinschreiben...
Es hat einen Grund das es sowas nicht gibt!
Grüße
Andreas-
Hallo Andreas,
ich möchte hier für meine zukünftigen Fragen ein für alle mal etwas klarstellen:
Ich frage in diesem hochqualifizierten Forum, weil ich in aller Regel ernsthafte und höfliche Antworten erhalte. Ab und zu ein humorvoller Seitenhieb lässt sich auch verkraften.
Verrätst Du mir warum Du das alles machen möchtest? Das kann man alles irgendwo nachlesen, wo weiß ich jetzt nicht und es interessiert mich auch nicht.
Wenn Du volle Kontrolle über die Session haben willst, schreibe Dir einen eigenen Session-Mechanismus oder benutze PERL.Wenn Dich etwas nicht interessiert, dann behalte Deine unqualifizierten Kommentare bitte in Zukunft für Dich. Ich bin übrigens nicht der Einzige, der sich daran stört, was für Antworten Du hier gibst. Aber die Anderen sollen da selber Laut geben.
Ich möchte auf Deine Kommentare jedenfalls in Zukunft verzichten.
Grüße aus http://www.braunschweig.de
Tom
-
Hallo!
Verrätst Du mir warum Du das alles machen möchtest? Das kann man alles irgendwo nachlesen, wo weiß ich jetzt nicht und es interessiert mich auch nicht.
Wenn Du volle Kontrolle über die Session haben willst, schreibe Dir einen eigenen Session-Mechanismus oder benutze PERL.Wenn Dich etwas nicht interessiert, dann behalte Deine unqualifizierten Kommentare bitte in Zukunft für Dich. Ich bin übrigens nicht der Einzige, der sich daran stört, was für Antworten Du hier gibst. Aber die Anderen sollen da selber Laut geben.
Ja, war vielleicht nicht so nett, war auch nicht so gemeint, sorry. Das ganze kommt mir nur etwas übertrieben vor, als würde man einen 5-seiteigen Aufsatz über die echo-Funktion schreiben. Ich kann mir nunmal nicht vorstellen wie Du 100-150 Seiten über PHP-Session füllen willst! Wenn Du mal die Überschriften postest klärt sich vielleicht einiges auf!
Grüße
Andreas-
Hallo Andreas,
ok, Schwamm drüber. Ich bin sowieso konsequent inkonsequent.
Ich kann mir nunmal nicht vorstellen wie Du 100-150 Seiten über PHP-Session füllen willst! Wenn Du mal die Überschriften postest klärt sich vielleicht einiges auf!
Das Thema heißt ja auch
"Sessionverwaltung und Authentifizierung in PHP4"
oder Authentifikation?
Na jedenfalls geht es um ein "Kochbuch", wie man das mit Hilfe von PHP4 löst und was trotz der mächtigen Funktionen noch alles schiefgehen kann.
Grüße aus http://www.braunschweig.de
Tom
-
-
-
-
Hallo,
Zu 1)
Wir haben in unseren Versuchen Session-Cookies erzeugt. Diese wurden allerdings im Cache des MSIE 5.5 nicht angezeigt, während "normale" Cookies immer zur Anzeige kamen. Meine Frage zeielte also darauf ab, ob es wohl in der Spezifikation für das Cookie ein Flag gibt, dass besagt: bitte nur im Hauptspeicher, nicht auf Festplatte.Ok, nur noch mal zum Verständnis, es gibt keine unnormalen Cookies also auch keine Normalen;) Es gibt ein Secure-Flag, wird aber meines Erachtens bei einem Session-Cookie nicht gesetzt. Das es nicht im IE erscheint, liegt wohl daran, dass ein No-Cache gesetzt wird. Es gibt also kein Flag, was sagt "Hey, ich bin ein Session-Cookie". Es ist der Webserver, der meint, dass es ein Session-Cookie ist (Session-ID). Und es ist auch der Webserver, der dem Cookie einen Namen gibt. Wie Sven schon sagte, im Session-Cookie steht meistens (kann sich ja in Zukunft auch ändern) nur die Session-ID. Es ist also einzig und allein der Webserver, welcher mit der Session-ID etwas anzufangen weiß. Für den Client ist und bleibt es ein stink normales Cookie.
[http://www.w3.org/Protocols/rfc2109/rfc2109]
hth
ralf-
Hallo Ralf,
... bei einem Session-Cookie nicht gesetzt. Das es nicht im IE erscheint, liegt wohl daran, dass ein No-Cache gesetzt wird.
Ja, vielen Dank. Das habe ich auch vermutet. Ich muss mich jetzt nochmal durch die Spezikikation quälen. Ich hoffe, dass Dein Link mir dabei weiterhilft.
[http://www.w3.org/Protocols/rfc2109/rfc2109]
CU
Tom
-
-
-
-
Hi!
nachdem wir uns nun zwei Tage zu Dritt mit den Sessions in PHP, aber vor allem mit den schlechten und teilweise widersprüchlichen Dokumentationen rumgeschlagen haben,
Ja? Ich finde die sehr gut! Was hast Du denn gelesen?
http://www.php3.de/manual/en/ref.session.php
http://www.php-faq.de/ch-version4_session.html
wo ist darin ein Widerspruch? Alles andere brauchst Du IMHO nicht!
Da steht IMHO alles was man wissen muss. Wenn Du wissen willst wie sich ein Sessioncookie vom normalen Cookie unterschiedet(ich weiß es nicht), mußt Du halt danach suchen, oder testweise beides erzeugen und den HTTP-Traffic belauschen und vergleichen. Das mußte ich auch bei meinen speziellen Socket-Verbindungen.haben wir einigermaßen Überblick erhalten. Wir sind nun dabei, eine eigene Doku zu erstellen, damit die teilweise leider nur empirisch ermittelten Zusammenhänge nicht wieder versickern. Ich habe gerade das Inhaltsverzeichnis geschrieben und bin auf mehr als 30 Überschriften ersten Grades gekommen. Es dürften also so ca. 100 bis 150 Seiten werden.
Hä? Zu PHP-Sessions? Dann poste doch mal bitte die Überschriften!
Wir haben nur mit den PHP-Grundfunktionen gearbeitet, also ohne die OOP-Lib. Außerdem haben wir uns ein paaar Hilfsmittel (Monitor-Programme) erstellt.
Einige Fragen bestehen aber noch, und die würde ich gerne mit Euch zusammen klären:
1.) Es gibt scheinbar Unterschiede zwischen einem "Session-Cookie" und einem "normalen" Cookie. Wie bilden die sich in der System-Programmierung oder im HTTP-Protokoll ab?
entweder bei google suchen oder selbst HTTP-traffic lesen!
2.) Wie kann ich einen solchen Session-Cookie auf der Workstation feststellen und auslesen? Gibt es Tools?
Der Session-cookie an sich und als solcher existiert nur für die Dauer der Session und nur in einem Browserfenster! Das ist ja gerade Sinn der Sache. Wenn ich mich nicht irre wird das bei den Browsern verschieden gehandhabt, meist bleibt der Sessioncookie im Arbeitsspeicher! Und wieso willst Du das auslesen? Der Browser schickt den Cookie doch eh, und auf Daten des Clients sollst Du eh nicht zugreifen!
Außerdem haben diese beiden Punkte herzlich wenig mit PHP zu tun, sondern mit HTTP und Browsern!3.) Welche offiziellen Möglichkeiten gibt es festzustellen, ob eine Session besteht? Wir haben nur die Auswerung der Konstante SID finden können.
???
Man könnte z.B. eine Variable in die Session schreiben, z.B. $_SESSION["ok"] = 1, und dann kannst Du einfach fragen if($_SESSION["OK"]), das sollte gut funktionierren. Aber die Frage ist ob man das überhaupt braucht! Denn wenn es nur darum geht zu testen ob der Browser bereits registriert ist, dann muß dieser ja auch die SessionID senden, also kannst Du einfach am Anfang des Scriptes prüfen ob die Variable entweder in $_POST[session_name()], $_GET[session_name()] oder in $_COCKIE[session_name()] steht, und evtl. noch mit der echten session_id() vergleichen. Man kann nicht für jede Kleinigkeit eine offizielle PHP-Funktion haben, wenn man sowas spezielles braucht dann schreibt man es sich selbst!4.) Gibt es eine Möglichkeit, ein session_register() direkt auf einzelen der $HTTP_POST_VARS auzuüben?
???
Wieso das? Mit Trans_sid wird automatisch die SessionID an alle Links und in alle Formulare, und auf Wunsch sogar in Javascript usw. geschrieben. Was in $HTTP_POST_VARS bzw. $_POST steht, ist das was der Browser Dir schickt. Was willst Du da registrieren? Außerdem verwendet man heute kein session_register() mehr, sondern $_SESSION["variable"] = $wert um Werte in eine Sessionvariable zu schreiben.
Daran alleine sieht man wie tief Ihr bereits in der Materie seid!Das sind die ersten Fragen. Die nächsten ergeben sich bestimmt beim Schreiben der Doku.
Also Sessions sind nun wirklich nicht schwer so schwer zu verstehen das man da eine 150 Seiten Doku bräuchte! Ich verstehe dagegen Deine Probleem nicht! Nenn mal konkrete Probleme, vielleicht brauchst Du die Doku ja doch nicht!
Grüße
Andreas-
Hallo Andreas,
darauf erwartest Du doch wohl von mir keine Antwort, oder?
Tom
-
-
Moin!
nachdem wir uns nun zwei Tage zu Dritt mit den Sessions in PHP, aber vor allem mit den schlechten und teilweise widersprüchlichen Dokumentationen rumgeschlagen haben, haben wir einigermaßen Überblick erhalten. Wir sind nun dabei, eine eigene Doku zu erstellen, damit die teilweise leider nur empirisch ermittelten Zusammenhänge nicht wieder versickern. Ich habe gerade das Inhaltsverzeichnis geschrieben und bin auf mehr als 30 Überschriften ersten Grades gekommen. Es dürften also so ca. 100 bis 150 Seiten werden.
Ich konnte bislang nicht feststellen, dass die PHP-Doku, die ich verwende, irgendwelche Widersprüche enthält - insbesondere der Session-Teil ist eigentlich recht simpel.
1.) Es gibt scheinbar Unterschiede zwischen einem "Session-Cookie" und einem "normalen" Cookie. Wie bilden die sich in der System-Programmierung oder im HTTP-Protokoll ab?
Die Unterschiede sind wirklich nur scheinbar. Ein Session-Cookie ist keine PHP-Spezialität, sondern ein Cookie, welches beim Beenden der Browser-_Session_ gelöscht wird - im Gegensatz zu persistenten Cookies, die eine Haltbarkeitsdauer mit auf den Weg bekommen haben. Sowas ist für ein Session-Management grundsätzlich eine gute Idee, denn ansonsten könnten andere Benutzer die Session auf dem gleichen Rechner einfach übernehmen.
2.) Wie kann ich einen solchen Session-Cookie auf der Workstation feststellen und auslesen? Gibt es Tools?
Willst du wissen, was drinsteht? Die Session-ID steht drin - erkennbar an den Daten, die PHP wieder vom Browser zurückkriegt, indem man $_COOKIES anguckt. Da $_COOKIES keinen direkten Bezug zur Session hat, sondern alle Cookie-Daten aus dem HTTP-Request wiedergibt, dürfte diese Information doch wohl ausreichend sein, oder? Ansonsten guck dir den HTTP-Verkehr an, am besten mit Michael Schröpls HTTP-Trace: http://www.schroepl.net/cgi-bin/http_trace.pl. Wie anderweitig schon angemerkt, gibt es für Session-Cookies keine Notwendigkeit zur Speicherung auf nichtflüchtigen Datenträgern, weil sie mit Beenden des Browsers ohnehin wieder gelöscht werden.
3.) Welche offiziellen Möglichkeiten gibt es festzustellen, ob eine Session besteht? Wir haben nur die Auswerung der Konstante SID finden können.
Schau in $_GET, $_POST und $_COOKIE nach, ob ein Schlüssel mit dem SessionID-Namen (gesetzt durch session_name() - default 'PHPSESSID') auftaucht. Wenn ja, besteht wohl eine Session - zumindest hat der Client von der vorhergehenden Seite dann eine Session-ID mitgebracht. Und PHP wird durch den Befehl session_start() nach gespeicherten Session-Informationen basierend auf diesen übermittelten Daten suchen.
4.) Gibt es eine Möglichkeit, ein session_register() direkt auf einzelen der $HTTP_POST_VARS auzuüben?
Damit würdest du vermutlich ein heftiges Kuddelmuddel erzeugen. Kopiere die für dich interessanten POST-Werte in eine Variable und registriere die in der Session. Denn bei der nächsten Seite könnte wieder ein POST-Request kommen und die Werte sich gegenseitig überschreiben.
Bemerke: Erst der Befehl session_start() schreibt die in der Session gespeicherten Werte in ihre zugehörigen Variablen. Vorher hast du nichts.
- Sven Rautenberg
-
Hallo Sven,
noch einige gute Tipps. Danke!
Ich konnte bislang nicht feststellen, dass die PHP-Doku, die ich verwende, irgendwelche Widersprüche enthält - insbesondere der Session-Teil ist eigentlich recht simpel.
in der offiziellen PHP-Doku steht leider nicht alles drin, was man sucht und die anderen scheinen nur mehr oder weniger sauber voneinander abzuschreiben und dabei entstehen dann öfter Fehler, meistens aufgrund der teilweise erheblichen Versionsunterscheide.
zu 1.)
auch PHP-Session-Cookies mit einer Lebensdauer > 0 werden nicht abgespeichert und auch nicht angezeigt. Das wird dann wohl an der zusätzlich mitgelieferten Cache-Strategie liegen??2.) Wie kann ich einen solchen Session-Cookie auf der Workstation feststellen und auslesen? Gibt es Tools?
Willst du wissen, was drinsteht? Die Session-ID steht drin - erkennbar an den Daten, die PHP wieder vom Browser zurückkriegt, indem man $_COOKIES anguckt.
Das haben wir natürlich als Erstes getan.
Leider beantwotest Du meine Drage auch nicht. Ich würde gerne auf dem Client feststellen, ob der Browser Session-Cookies hält. Ist ja mein gutes Recht, festzustellen, welche fremden Daten mit (temporär) aufs Gerät gespeilt werden.
Schau in $_GET, $_POST und $_COOKIE nach, ob ein Schlüssel mit dem SessionID-Namen (gesetzt durch session_name() - default 'PHPSESSID') auftaucht.
Danke für den Tipp. Werde ich gleich kontrollieren, ob das stimmt.
4.) Gibt es eine Möglichkeit, ein session_register() direkt auf einzelen der $HTTP_POST_VARS auzuüben?
Damit würdest du vermutlich ein heftiges Kuddelmuddel erzeugen.
Ein Kuddelmuddel haben wir jetzt schon, da jede PHP-Version seit 3.x hier erhebliche Unterschiede und teilweise auch heftige Bugs aufweist. Ich muss nun versuchen, einen einigermaßen durchgängigen Leitfaden seit Einführung der Sessions in PHP zu erstellen.
Bemerke: Erst der Befehl session_start() schreibt die in der Session gespeicherten Werte in ihre zugehörigen Variablen. Vorher hast du nichts.
<blockquote>
variables_order = "EGPCS" ; This directive describes the order in which PHP registers GET, POST, Cookie, Environment and Built-in variables (G, P, C, E & S respectively, often referred to as EGPCS or GPC). Registration is done from left to right, newer values overwrite older
</blockquote>Soweit war ich schon. Ich bin nicht zu faul zu lesen ;-) Trotzdem ist jede ernsthafte konstruktive Kritik hilfreich.
Ich danke Dir
Tom
-
Moin!
in der offiziellen PHP-Doku steht leider nicht alles drin, was man sucht und die anderen scheinen nur mehr oder weniger sauber voneinander abzuschreiben und dabei entstehen dann öfter Fehler, meistens aufgrund der teilweise erheblichen Versionsunterscheide.
Dann halte dich nur an das offizielle Dokument und deren User-Anmerkungen. ;)
zu 1.)
auch PHP-Session-Cookies mit einer Lebensdauer > 0 werden nicht abgespeichert und auch nicht angezeigt. Das wird dann wohl an der zusätzlich mitgelieferten Cache-Strategie liegen??Ich hab keine Ahnung. Aber das Cookie, was durch die Session gesetzt wird, ist keine schwarze Magie, sondern ein stinknormales Cookie, wie es von jedem anderen Mechanismus auch gesetzt werden kann. Es gibt schließlich nur eine Art von Cookies in HTTP. :)
2.) Wie kann ich einen solchen Session-Cookie auf der Workstation feststellen und auslesen? Gibt es Tools?
Willst du wissen, was drinsteht? Die Session-ID steht drin - erkennbar an den Daten, die PHP wieder vom Browser zurückkriegt, indem man $_COOKIES anguckt.
Das haben wir natürlich als Erstes getan.
Leider beantwotest Du meine Drage auch nicht. Ich würde gerne auf dem Client feststellen, ob der Browser Session-Cookies hält. Ist ja mein gutes Recht, festzustellen, welche fremden Daten mit (temporär) aufs Gerät gespeilt werden.
Mit Javascript gespeicherte Cookies abfragen? Das ist jedenfalls die einzige mir bekannte clientseitige Schnittstelle zu Cookies.
Schau in $_GET, $_POST und $_COOKIE nach, ob ein Schlüssel mit dem SessionID-Namen (gesetzt durch session_name() - default 'PHPSESSID') auftaucht.
Danke für den Tipp. Werde ich gleich kontrollieren, ob das stimmt.
4.) Gibt es eine Möglichkeit, ein session_register() direkt auf einzelen der $HTTP_POST_VARS auzuüben?
Ein Kuddelmuddel haben wir jetzt schon, da jede PHP-Version seit 3.x hier erhebliche Unterschiede und teilweise auch heftige Bugs aufweist. Ich muss nun versuchen, einen einigermaßen durchgängigen Leitfaden seit Einführung der Sessions in PHP zu erstellen.
Wenn du _alle_ PHP-Versionen erschlagen willst, hast du in der Tat reichlich zu tun. Dir wird nicht entgangen sein, dass erst PHP 4 eigene Session-Funktionen mitbringt, während PHP 3 dazu noch die PHPLIB brauchte - von daher also einen grundsätzlichen Unterschied birgt.
Ansonsten hast du "nur noch" mit den Funktionen zu kämpfen, die erst nach und nach fehlerbereinigt oder überhaupt eingebaut wurden. Ich würde dieses Problem aber eher als geringer einschätzen, weil die Lösung dazu sich zumindest leicht dahersagt: Neueste PHP-Version einspielen und gut. ;)
Bemerke: Erst der Befehl session_start() schreibt die in der Session gespeicherten Werte in ihre zugehörigen Variablen. Vorher hast du nichts.
<blockquote>
variables_order = "EGPCS" ; This directive describes the order in which PHP registers GET, POST, Cookie, Environment and Built-in variables (G, P, C, E & S respectively, often referred to as EGPCS or GPC). Registration is done from left to right, newer values overwrite older
</blockquote>Soweit war ich schon. Ich bin nicht zu faul zu lesen ;-) Trotzdem ist jede ernsthafte konstruktive Kritik hilfreich.
Ähm, dein Zitat zielt vollkommen an meiner Äußerung vorbei. Die Session-Variablen (also die Werte, die weitergereicht werden sollen), sind nicht in EGCPS gespeichert, werden also von dieser Direktive absolut nicht berührt. Die Session-Variablen werden per default (du kannst eigene Mechanismen definieren) in einer Textdatei abgelegt und erst beim Befehl session_start() eingelesen und den Variablen wieder zugewiesen.
Beispiel: Wenn du eine Variable $counter hast, die als Session-Variable registriert ist und dort mit dem Wert 23 abgespeichert wurde, dann passiert sowas:
<?php
echo $count; // gibt den Defaultwert einer nicht-initialisierten Variablen aus (nichts)
$count = 5;
echo $count; // gibt 5 aus
session_start();
echo $count; // gibt 23 aus?>
- Sven Rautenberg
-
Hallo Sven,
damit Du jetzt nicht in die Irre läufst:
Die zitierte Reihenfolge ist dafür verantwortlich, in welcher Reihenfolge die Variablen wieder bereitgestellt werden. Und wenn Du dann z.B. register_globals auf ON stefen hast, werden die Scritpvariablen (also die einfachen $var) in genau dieser Reihenfolge überschrieben. Wenn Du session.auto_start auf ON stehen hast, wird sie vollkommen eingehalten. Wenn die Session erst vom Script gestartet wird, dann werden die Session-Variablen erst dann beeitgestellt. Wenn register_globals auf ON steht, wird Deine Variable $counter (siehe unten) auch überschrieben.<blockquote>
variables_order = "EGPCS" ; This directive describes the order in which PHP registers GET, POST, Cookie, Environment and Built-in variables (G, P, C, E & S respectively, often referred to as EGPCS or GPC). Registration is done from left to right, newer values overwrite older
</blockquote>Ähm, dein Zitat zielt vollkommen an meiner Äußerung vorbei. Die Session-Variablen (also die Werte, die weitergereicht werden sollen), sind nicht in EGCPS gespeichert, werden also von dieser Direktive absolut nicht berührt. Die Session-Variablen werden per default (du kannst eigene Mechanismen definieren) in einer Textdatei abgelegt und erst beim Befehl session_start() eingelesen und den Variablen wieder zugewiesen.
Beispiel: Wenn du eine Variable $counter hast, die als Session-Variable registriert ist und dort mit dem Wert 23 abgespeichert wurde, dann passiert sowas:
<?php
echo $count; // gibt den Defaultwert einer nicht-initialisierten Variablen aus (nichts)
$count = 5;
echo $count; // gibt 5 aus
session_start();
echo $count; // gibt 23 aus?>
Klar dass das nicht funktioniert, weil Deine registrierte Variable ja $counter heißt ;---)
Aber ensthaft: Außerdem würde Dein Beispiel ausgeben, dass die Session nicht gestartet werden kann, da die HTTP-Header schon gesendet sind. Grundregel Nummer eins: kein Session-Start mehr nach einer Ausgabe an den Browser. Man müsste die Ausgaben also zumindest zwischenspeichern.
session_start() und auch session_register() lösen die nachträgliche Kopplung zur Session aus (wenn man nicht session.auto_start=1 bestimmt hat).
Und dann würde Deine Variable $counter auch nur dann überschrieben, wenn Du register_globals=1 gesetzt hast. Es wäre jetzt noch interessant, welcher Wert siegt, wenn man register_globals=0 eingestellt hat und jetzt ein session_register(counter) (das geht mit und ohne Häkchen!) ausführen lässt.
Es ist gut, dass ich gerade mit Dir diese Haken und Ösen hier diskutieren kann. Da habe ich schon überaus positive Erfahrung in der Vergangenheit gemacht. Ich will ja gar nicht Recht haben, nur nachher auch nichts Falsches schreiben.
Du siehst jezt wahrscheinlich selbst, dass ca. 30 Seiten für den ganz geraden Weg und 150 Seiten für die Besprechnung von Irrungen und Wirrungen nicht zuviel sind. Zumal ich ja auch noch eine "Login-Strategie" darin anreißen will.
Die teilt sich dann nochmal, in Login mit und ohne Datenbank. Dabei hilft mit (ich hoffe, er hat es noch nicht vergesen) Fabian. Das gibt dann bestimnmt nochmal 30-70 Seiten.
Jetzt ist aber Schluss, sonst überschreite ich nachher noch die MAX_POST_LINES.
Grüße aus http://www.braunschweig.de
Tom
-
-
-