Hallo, ich würde gerne wissen, was ihr nehmen würdet - Sessions oder Coockies??
Sessions sind sicherer, aber könnte ich länger nutzen.
Was würdet ihr mir empfehlen?
Grüße,
Sebastian
Zu lernen, Fragen so zu stellen, dass sie auch beantwortbar sind.
Ohne, dass du sagst, was du überhaupt machen willst, ist diese Frage es definitiv nicht - da könnte man dir auch als dritte Alternative vorschlagen, “nimm Kieselsteine!”
Und wenn du dir schon eigene Gedanken dazu gemacht hast, welche der beiden Techniken für das konkrete Vorhaben welche Vor- und welche Nachteile haben könnte - dann schreib diese auch dazu.
Eine Aussage wie “Sessions sind sicherer” ist jedenfalls unsinnig, wenn noch nicht mal definiert wird, in Bezug worauf eigentlich.
sry hab ich ganz vergessen 
ich mag damit ein loginsystem machen bzw. es abändern.
jetzt möchte ich wissen, was die bessere wahl ist.
(evtl. auch ne mischung aus beidem)
Ja - und deine eigenen Gedanken dazu …?
Wenn du dafür nur Cookies verwenden würdest, müsstest du die relevanten Infos, also Username und Passwort, bei jedem Request mitschicken - und auch jedes Mal wieder neu prüfen. (Etwas abgemildert würde die Problematik, wenn man nur einen Hash aus Username und Passwort mitschicken würde - aber auch der wäre jedes Mal wieder zu überprüfen.)
In einer Session hingegen kannst du die Information, dass ich mich bereits erfolgreich angemeldet habe, ablegen - und brauchst dann nur noch auf diese zu prüfen, aber nicht mehr jedes Mal Name und Passwort.
ich verwende cookies nur wenn diese mithilfe von JS gelesen werden müssen oder den benutzer für längere zeit indentifiziert werden muss; für alles andere sessions.
zum loginsystem: ganz klar sessions, aber für eine “ich möchte eingeloggt bleiben” funktion ein cookie mit nummer die beim neuaufrufen abgeglichen wird bevor eine session erzeugt wird.
okay, danke.
dann werde ich wohl weiterhin sessions nutzen^^
eine PHP session nutzt doch ebenfalls cookies, bzw. versucht cookies zu nutzen.
Der wesentliche unterschied ist wohl, dass bei php-sessions sämtliche Funktionen für eine verwaltung von sessions bereits gegeben ist.
Der Cookie den die PHP Session-funktion anlegt heißt standardmäßig “PHPSESSID”. kann man sogar im Browser nachschauen.
Wenn man sagt, dass man “Cookies benutzt” bedeutet das nichts anderes, als das man die session-funktionen von PHP selber programmiert.
Der Vorteil ist, dass man die Daten, die normalerweise PHP-Sessions in eine Datei speichert, in eine MySQL Tabelle ablegen kann, und direkt mit anderen Tabellen verknüpfen kann. Außerdem hat man so ein klein wenig mehr kontrolle über dem was und wie die Dinge gespeichert werden, als bei den normalen PHP-Sessions.
Ich persönlich bevorzuge die selbstgebaute Variante. Ich verzichte also auf die PHP-Sessions.
mfg Balmung
Sessions sind eine Möglichkeit, über ein zustandsloses Protokoll wie HTTP eine “Wiedererkennung” des Clients zu ermöglichen, um ihm bestimmte Daten serverseitig zuordnen zu können.
Dass diese Daten serverseitig vorgehalten werden, schliesst die ungewollte Manipulation durch den Client aus. Wenn ich die Information “4 + 4 ist gleich 8” auf einer Folgeseite zur Verfügung stehen haben möchte, dann könnte ich sie den Umweg über den Client machen lassen - sie in einem Cookie speichern, oder per GET/POST übermitteln lassen. Dabei kann aber nichts und niemand den Client daran hindern, diese Information in “4 + 4 ist gleich 13” zu ändern, bevor er sie an den Server schickt.
Nutze ich hingegen Sessions, und lege darin die Information “4 + 4 ist gleich 8” ab - dann hat der Client keine Möglichkeit, diese Info zu verändern. Er schickt mir lediglich bei seinem nächsten Request eine Session-ID mit, über die ich in identifizieren kann - und ihm dann sagen, “Hey, du bist doch der, mit dem ich mich eben schon darüber unterhalten habe, dass 4 + 4 gleich 8 ist.”
Kann, muss aber nicht.
Die Übergabe einer ID ist ein wesentliches Merkmal von Sessions - aber diese ID kann auf verschiedenen Wegen übergeben werden; Cookies sind lediglich in der Vielzahl der Fälle die “bequemste” und oftmals auch “sicherste” Variante.
Nein - man “muss” Cookies nicht benutzen, um eine Session-Funktionalität zu implementieren.
Z.B. clientseitige Präferenzen kann man gut darin ablegen, bspw. die Auswahl eines bestimmten Seiten-Styles. Diese Information ist nur für den Client interessant - serverseitig interessiert sie mich nicht. Dass auch solche Cookies mit jedem Request an den Server übergeben werden, ist prinzipbedingt - macht das ganze aber noch lange nicht zu einer “Session”.
Diese Kontrolle kann man auch haben, wenn man den Session-Mechanismus von PHP nutzt. Wo die Daten abgelegt werden, kann man selber bestimmen - das könnte neben der Speicherung in Dateien bspw. auch in einer Datenbank oder shared memory passieren.
Kann man machen, wenn man darin Vorteile für die eigenen Applikation erkennt, die man mit dem Standardmechanismus nicht hätte.
Ist für Anfänger aber weniger empfehlenswert, da man sich u.U. um so Dinge wie Locking und GC selber kümmern muss.
Sessions sind durchaus aber praktisch, vor allem weil man sich mit sehr einfachen Mitteln nicht mehr auf die Cookies verlassen muss. Einfach die Session-ID per GET oder POST mitgeben und die Sache hat sich auch erledigt.
Solch eine Sitzung sollte jedenfalls auch funktionieren, wenn der
Nutzer cookies ablehnt. Und wenn man dem Nutzer erfolgreich
nahebringen kann, daß die cookies einen Sinn ergeben, von dem
dieser unmittelbar profitiert, sollte man auch darauf achten, daß
der pro Seitenaufruf nicht mehr als einen cookie bekommt.
Ich etwa reagiere leicht genervt, wenn ich bei einem Seitenaufruf
plötzlich 20 cookies bestätigen oder ablehnen soll, ohne einen
für mich ersichtlichen Nutzen zu erkennen. Solche Seiten
bekommen dann bei mir gleich die pauschale Einstellung,
automatisch alle cookies abzulehnen, schon um die Nerven zu
schonen.
Somit sollte also der Zugang zum Inhalt nicht von optionalen
Techniken abhängen, zu denen eben auch cookies, js etc
gehören, sonst erweckt das Projekt schnell den (zutreffenden)
Eindruck, für den Besucher eine blödsinnige Zeitverschwendung
zu sein ;o)
