nicht angemeldet
wie eine Session verfolgen wenn cookies nicht erlaubt sind?
Hallo,
ich möchte ein kleines php Projekt schreiben bei den sich der Benutzer anmelden kann (aber nicht muss). Dann muss auf ca. fünf bis zehn aufeinander folgenden Seiten jeweils eine Option ausgewählt werden. Am Schluß werden die gesammelten Optionen noch einmal angezeigt und auf dem Server gespeichert. Je nachdem, ob sich der Benutzer angemeldet hat oder nicht, wird evtl. auch der Benutzername mit gespeichert.
Die Benutzeranmeldung wollte ich mit einer php Session speichern und verfolgen, die ausgewählten Otionen von einer Seite zur nächsten mit POST oder GET (als immer länger werdende query) weitergeben.
Nun muss das ganze auch dann funktionieren, wenn einer auf seinem Browser die cookies abgeschaltete hat.
Muss ich das "zu Fuß" prüfen und dann bei jedem Link einzeln an die bestehende query (die die bisher gewählten Optionen repräsentiert) die PHPSESSID anhängen oder macht das php irgendwie automatisch?
Das ganze sollte bei POST und bei GET funktionieren.
Liebe Grüße
Anja
-
Hallo,
Die Benutzeranmeldung wollte ich mit einer php Session speichern und verfolgen, die ausgewählten Otionen von einer Seite zur nächsten mit POST oder GET (als immer länger werdende query) weitergeben.
nein, natürlich nicht. Du möchtest ganz bestimmt die ausgewählten Optionen in der Session speichern. Keine hidden inputs und keine ellenlangen Querystrings.
Freundliche Grüße
Vinzenz
-
Hallo Vinzenz,
... Keine hidden inputs und keine ellenlangen Querystrings.
Und wie bekomme ich dann die Informationen von einer Seite zur nächsten wenn die cookies nicht erlaubt sind?
BTW: oder sollte man heutzutage einfach davon ausgehen, dass cookies fast bei jedem erlaubt sind und auf die paar Leute pfeifen...?
LG
Anja-
Und wie bekomme ich dann die Informationen von einer Seite zur nächsten wenn die cookies nicht erlaubt sind?
RTFM. Du wirst es kaum glauben, aber wenn du die Werte in der Session speicherst, gibt es eine Möglichkeit die Session-ID auch ohne Cookies an den nächsten Request/Response weiterzureichen.
BTW: oder sollte man heutzutage einfach davon ausgehen, dass cookies fast bei jedem erlaubt sind und auf die paar Leute pfeifen...?
Man sollte eher vom Gegenteil ausgehen.
-
-
Hello,
Die Benutzeranmeldung wollte ich mit einer php Session speichern und verfolgen, die ausgewählten Otionen von einer Seite zur nächsten mit POST oder GET (als immer länger werdende query) weitergeben.
nein, natürlich nicht. Du möchtest ganz bestimmt die ausgewählten Optionen in der Session speichern. Keine hidden inputs und keine ellenlangen Querystrings.
Ein einziges Hidden-Element würde ja auch reichen, wenn sowieso per Post "weitergeschaltet" werden soll. Das Datenarray einfach vorher serialisieren und dann durch base64encode() schicken. Das hat auch den Vorteil, dass die Daten dadurch "laiensicher" sind, also nicht im Klartext drinstehen und auch nicht "mal eben schnell" manipuliert werden können.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Moin Moin!
Ein einziges Hidden-Element würde ja auch reichen, wenn sowieso per Post "weitergeschaltet" werden soll.
Soweit richtig.
Das Datenarray einfach vorher serialisieren und dann durch base64encode() schicken. Das hat auch den Vorteil, dass die Daten dadurch "laiensicher" sind, also nicht im Klartext drinstehen und auch nicht "mal eben schnell" manipuliert werden können.
Mumpitz! In das Hidden-Feld kommt die Session-ID, fertig. Manipulationssicher, i.d.R. kompakter und auch von Profis Client-seitig nicht manipulierbar.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Hello,
Ein einziges Hidden-Element würde ja auch reichen, wenn sowieso per Post "weitergeschaltet" werden soll.
Soweit richtig.
Das Datenarray einfach vorher serialisieren und dann durch base64encode() schicken. Das hat auch den Vorteil, dass die Daten dadurch "laiensicher" sind, also nicht im Klartext drinstehen und auch nicht "mal eben schnell" manipuliert werden können.
Mumpitz!
Lies doch erst mal nach, worum es ging, bevor Du polterst. Prinzipiell hättest Du ja auch Recht. Wenn man den Gedanken dann noch weiter verfolgt, ist man doch sowieso bei der Lösung angekommen, die PHP für transiente Session-IDs benutzt.
Wenn aber keine Session gewünscht wird, weil z.B. auf dem Srever keine Daten persistent gespeichert werden dürfen, oder die Sessionlösung aus technischen Gründen (vermeintlich) nicht genutzt werden kann, dann ist ein gepacktes oder serialisiertes "Huckepackelement" eine praktische Lösung. Man muss keinesfalls Dutzende diskrete Hidden-Elemente aufbauen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-
-
-
Moin!
Muss ich das "zu Fuß" prüfen und dann bei jedem Link einzeln an die bestehende query (die die bisher gewählten Optionen repräsentiert) die PHPSESSID anhängen oder macht das php irgendwie automatisch?
Wundere mich, warum noch niemand das Offensichtliche geantwortet hat (jedenfalls nicht nett formuliert): Ja, PHP kann das ganz von alleine, wenn man die Optionen richtig konfiguriert hat.
In der Regel will man die Session-ID bestmöglich vor unerlaubtem Zugriff durch Dritte schützen, deshalb wird eine Webapplikation ausschließlich Cookies benutzen, und diese auch HTTP-only und (bei SSL) secure setzen.
- Sven Rautenberg
-
Lieber Sven Rautenberg,
In der Regel will man die Session-ID bestmöglich vor unerlaubtem Zugriff durch Dritte schützen
ja, das will man. Aber seinen Willen bekommt man nicht immer erfüllt...
deshalb wird eine Webapplikation ausschließlich Cookies benutzen
Damit sperrst Du User aus, bei denen Cookies (aus welchen Gründen auch immer) gesperrt sind.
und diese auch HTTP-only und (bei SSL) secure setzen.
Was machen denn die Freehoster mit ihren Webmail-Interfaces? Setzen die allesamt zwingend auf Cookies? Bei GMX habe ich nicht den Eindruck! Und was machst Du, wenn ich in einem zweiten Browserfenster mit einer anderen Identität dieselbe Webapplikation nutzen möchte? Da spuckt mir dann das Cookie gehörig in die Suppe!
Du hast in einem Punkt absolut Recht: Wenn die Session-ID im URI steht, kann sie wesentlich leichter "entführt" werden, insbesondere, wenn sich der User nicht korrekt abmeldet. In diesem Falle könnte ein pöhser Pube aus der History eine Seite aufrufen und dann mit der Applikation gemeine Sachen anstellen.
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)-
Hi,
Und was machst Du, wenn ich in einem zweiten Browserfenster mit einer anderen Identität dieselbe Webapplikation nutzen möchte? Da spuckt mir dann das Cookie gehörig in die Suppe!
Dafür gibt es privates Browsen. Da hast du deinen eigenen Satz an Cookies.
Bis die Tage,
Matti -
Hello,
Da spuckt mir dann das Cookie gehörig in die Suppe!
Man kann bekanntermaßen für dieselbe Domain auch diverse unterschiedliche Cookies senden (setzten lassen, wenn der Client mitspielt).
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
-