Hallo ich weis nicht ob die frage in diesem forum richtig psitioniert ist aber ich habe ein Problem bzw eine Frage.

Auf meiner Webseite werden viele Daten von leuten abgefragt und zwischengespeichert (in Cookies).

Mein problem ist das am ende offtmals Cookies gelöscht werden, da zu viele erstellt werden.

Wie kann ich mehr Daten zwischenspeichern und wieder darauf zugreifen?

Über die Post variante werden es auch zu wenig sein.

Sessions -> http://de2.php.net/manual/de/features.sessions.php
Datenbanken, Dateien, APC, ....

Speicher die daten in der session..
http://de2.php.net/manual/de/book.session.php

Session ist natürlich ein cooles Feature von PHP, aber genau dort fängt der Glaubenskrieg an. Um Daten von einer Seite zur nächsten durchzureichen gibt es natürlich auch andere Möglichkeiten.

z.B. über den get Parameter

man codiert es in einen Url conformen String, selbst arrays kann man so übertragen.

PHP-Code:

function base64url_encode($data) {
                return rtrim(strtr(base64_encode($data), '+/', '-_'), '=');
        } 


will man sie dann wieder als Daten haben, dann gibt es diese Funktrion.

PHP-Code:

function base64url_decode($data) {
 return base64_decode(str_pad(strtr($data, '-_', '+/'), strlen($data) % 4, '=', STR_PAD_RIGHT));
} 


Wie das Beispiel zeigt, ist es nur eine Frage der Programmierung. Gute Programmierung zeichnet sich dadurch aus, gänzlich ohne Session auszukommen.

SCHLUSSWORT: Cookies alias Sessions sollen nur den Benutzer wieder erkennen oder Benutzer spezifische Daten speichern die nicht relevant sind. Stichwort Cookie Manipulation.

Das Problem bei Cookies ist, dass man sie wenn schon verschlüsselt speichern sollte, denn sonst könnte man die Daten sehr einfach ändern.

Nehmen wir an, man prüft, ob jemand ein Admin ist mit folgendem Code:

PHP-Code:

function isAdmin()
{
  if ( isset($_COOKIES['admin']) && $_COOKIES['admin']==="1" )
    return true;
  return false;
} 


Dann bräuchte man nur so ein Cookie erstellen oder vielleicht sogar nur ändern, auf den Wert 1 legen und fertig!

Wie das Beispiel zeigt, ist es nur eine Frage der Programmierung. Gute Programmierung zeichnet sich dadurch aus, gänzlich ohne Session auszukommen.

Das sehe ich nicht so. Wo willst du denn sensible Daten (wie den gerade angemeldeten Nutzer) speichern?
Du hast ja selber das Stichwort erwähnt: Cookie Manipulation.

Zwar sind PHP Sessions im Prinzip auch nur ein Cookie, aber von der Clientseite her, kann man die Daten nicht einsehen oder gar verändern! Das kann nur jemand, der Zugriff zum Sessionspeicherort hat.
Man kann die Sessions auch in der Datenbank speichern (mittels eigenem Session-Handler), wenn man sie nicht (wie in der Standardeinstellung) in Dateien im temporären Ordner speichern möchte.

Da hast du natürlich recht, aber was manche Leute im Cookie speichern... ich habe es schon gesehen das der Cookie > 500kb war. Cookie in der DB ist ein guter Weg, zumal es ein muß bei Cloud computing alias Cluster(so nannte man es früher) ist. Wie ich schon geschrieben habe, der Cookie dient zum wieder erkennen, mehr nicht! Den Rest machst du über deine Programmierung und schon hast du keine Sicherheitsprobleme mehr... wenn du es richtig machst...

Achso... Den Get Parameter bekommt natürlich nur ein authentfizierter User, das habe ich da einfach mal vorausgesetzt.

Du solltest in dem Fall auch immer daran denken, das der Cokkie übertragen wird zum Client. Also ergo Performance geht gegen NULL.

Zitat von Chewbacca

... ich habe es schon gesehen das der Cookie > 500kb war.

Cookies über 4KB werden denn von welchen Browser akzeptiert?

Zitat von Chewbacca

Cookie in der DB ist ein guter Weg,

Ein Cookie in der Datenbank? WTF Ein Cookie ist auf einem Clienten gespeichert.

Zitat von Chewbacca

Du solltest in dem Fall auch immer daran denken, das der Cokkie übertragen wird zum Client. Also ergo Performance geht gegen NULL.

Jeder Cookie wird nur einmal zum Clienten übertragen, außer er wird modifiziert. Danach schickt der Client die Cookie Informationen zum Server.

Zitat von Chewbacca

Gute Programmierung zeichnet sich dadurch aus, gänzlich ohne Session auszukommen.

Das ist ja mal völliger Quatsch!

Ja es sind mir schon ein paar Fehler unterlaufen...
Zum Ersten, ich meinte natürlich die Session, somit erklärt sich auch Zweitens und Drittens. Hatte das ein bisschen durcheinander gebracht.

Man kann natürlich alles in der Session speichern, nur wozu gibt es Get oder Post Variablen? Es ist doch toll, wenn ich auf eine Seite komme, wo dann steht "Sie müßen Cookies akzeptieren um die Seite sehen zu können".

Das ganze natürlich in einen Non Memberrange.... klasse...

Zitat von Chewbacca

nur wozu gibt es Get oder Post Variablen?

Nicht, um (übertrieben) die ganze DB darin zu speichern.

Zitat von Chewbacca

Es ist doch toll, wenn ich auf eine Seite komme, wo dann steht "Sie müßen Cookies akzeptieren um die Seite sehen zu können".

Wer sagt denn, dass Sessions auf Cookies beschränkt sind?

Zitat von sheel

Nicht, um (übertrieben) die ganze DB darin zu speichern.

Warum speichern? übertragen wäre richtig, speichern tut die Session eine Datei(liegt standardmäßig bei php im /tmp). Ich sage doch es ist ein Glaubenskrieg, wobei ich sagen muß es gibt wirklich sinnvolle Anwendungen für eine Session z.B. ein Warenkorb. Mir ging es nur darum zu zeigen daß es noch andere Möglichkeiten gibt. Klar können wir alles in einer Session speichern. Nur welchen Sinn bringt es?

Zitat von sheel

Wer sagt denn, dass Sessions auf Cookies beschränkt sind?

Eine Session kann nur funktionieren, wenn ein Cookie gesetzt ist oder woher bekommst du die SID vom User? Ach ja SID als Get.... was hatte ich nochmal geschrieben....

Glaubenskrieg? Weis nicht wie du dazu kommst dieses Wort
in diesem Zusammenhang zu verwenden.

Eine Session ist Serverseitig gespeichert
und kann vom Script immer wieder abgefragt werden.

Natürlich sollte man auch dort nur das Nötigste zwischenspeichern.
Jedoch sind sensible Daten nicht für Cookies gedacht.
Diese werden wenn sie den unbedingt müssen in der Session Abgelegt.

Diese wird durch die Session-ID wieder hergestellt wenn diese ausläuft,
falls dies erwünscht ist bzw. diese Grundlage vom Script her gegeben ist.

Cookies hingegen sind Clientseitig gespeichert,
werden bei jedem aufruf wieder an den Server gesendet
und vorallem können sie auch Manipuliert werden.


---------------------------------

Hier wurde nach einer Alternative für Cookies gefragt,
in welcher mehr Daten abgelegt werden können => Session.
Die Session kann ruhig mehr Daten enthalten.
z.B. Benutzerinformationen die ständig abgefragt werden,
werden in dieser zwischengespeichert.
Da sonst die Datenbank abfragen zu viel Performance fressen würden.
Natürlich sollte man keine ganze Datenbank darin speichern.
Aber in Cookies sollte diese schon garnicht landen,
was insbesondere für sensible Daten wie Passwörter gilt.

Zitat von Chewbacca

Eine Session kann nur funktionieren, wenn ein Cookie gesetzt ist oder woher bekommst du die SID vom User? Ach ja SID als Get.... was hatte ich nochmal geschrieben....

Eine Session funktioniert auch ohne Cookie.
Ohne Cookie kann sie nur nicht wiederhergestellt werden,
wenn eben diese Session ausgelaufen ist.

GET und POST variablen können am einfachsten manipuliert werden.
Für die Leute, welche nun denken häää man kann POST variablen nicht verändern,
guckt euch mal zum Beispiel das Addon "Temper Data" für Firefox an.
Davon ma abgesehen kann ich es überhaupt nicht leiden,
wenn ich auf einer Seite bin und sich die url mit jedem klick verlängert
und ich am ende ne 500 stellige Url kopieren muss.
Die URL sollte möglichst sauber bleiben
um die weitergabe eines Links zu vereinfachen.


Abwägen welche Daten man
zwischenspeichert oder übergibt,
sollte man in jedem fall.


Soo, wer Rechtschreib oder Gramatik fehler findet darf sie behalten.
Gerade keine Zeit nochmal alles durch zu lesen was ich geschrieben habe.

Wir sind doch einer Meinung... aber wir können weiter Spass machen.... also für Gets länger 500 Zeichen gibt es tinyurl...

Klar kann ich jeden Get oder Post ändern, aber habe dich das nicht schon geschrieben? Es wird nur bei eindeutiger Aithentifizierung ausgeliefert.

Session sind nur für die Sitzung gültig, damit hast du Recht. Bringt die Sache aber nicht weiter...

OK... Ein Plus für Sessions ist, ein Dateizugriff geht schneller als eine DB Abfrage. Weshalb wir ja auch nur Daten mit denen wir weiterarbeiten wollen in der DB speichern.

Jetzt stelle dir mal vor ich kapere dein Cookie und damit deine SID... huchu freie Auswahl überall...

Schlusswort: Session mit den Wiedererkennungs Cookie sinnvoll einsetzen, super alles andere leichter Irrglaube. es gibt ein Haufen Tools die die Wahrheit an das Licht bringen. Aber macht was ihr wollt, bevor es ihr ein Off Topic wird...

Gegen Session Hijacking kann man nicht viel machen.
Höchstens die Session an eine Netzwerkaddresse binden
und oder an den Browser Agent.

Aber die Person kann auch wenn er/sie die Session gekapert hat,
nicht die Daten aus eben dieser auslesen.
Und wenn du so argumentierst,
was ist den sicherer?
.. Passwort abfrage bei jeder Aktion auf der Seite?
ähhh ne danke xD

Und nur ma so am rande...
Ich halte nichts von TinyURL
Davon abgesehen wer will die url
immer erst da rein kopieren?
Hätt ich kein bock zu. <.<

/Offtopic

Zitat von Chewbacca

OK... Ein Plus für Sessions ist, ein Dateizugriff geht schneller als eine DB Abfrage. Weshalb wir ja auch nur Daten mit denen wir weiterarbeiten wollen in der DB speichern.

Die Datenbank lädt einige Daten in den Arbeitsspeicher, von daher kann es schon dazu kommen, dass der Zugriff auf die DB schneller ist.
Aber gut - das sind eh so wenige Millisekunden, das macht nichts aus !


@stikmata:

Hat sich denn das Problem jetzt erledigt?

War ja auch nur Spass, ich halte auch nichts von den services. Die sind einfach zu schnelllebig(tolles wort mit drei l... )

Was hälst du von einer guten und sinnvollen "csrf protection"... ist zumindest mal ein Anfang.