Cookies in PHP?
Geigerzeiger 28.01.2004 - 18:45 1222 26
dio
Here to stay
|
Schlechter Stil und keine Ahnung von der Materie kommt mir. Vermutlich sind dir Menschen mit besonderen Beduerfnissen auch egal, weil sie in der Minderheit sind, right?
Jemand der sich auskennt, fuer den stellt es keine besondere Arbeitsanforderung dar, es mit Sessions&Cookies gemeinsam umzusetzen. lies genau, ich hab gesagt bei einer normalen site mit weiss ned wievielen besuchern - und da der thread starter anscheinend noch nix mit cookies / sessions zu tun hat... was soll des
|
Rektal
Here to stay
|
Seh ich anders  Wenn der Thread-Starter gleich in die Wiege mitbekommt wie mans richtig umsetzt ist ihm eher geholfen.
|
dio
Here to stay
|
Seh ich anders Wenn der Thread-Starter gleich in die Wiege mitbekommt wie mans richtig umsetzt ist ihm eher geholfen. jo, is deine meinung  ich hatte anfangs probleme mit sessions, desshalb hab ich auch zu cookies geraten - meine meinung
|
Rektal
Here to stay
|
Dazu hab ich auch eine Meinung: dann soll er hier fragen, hier wird ihm Kompetent (wer lacht da? setzen!) geholfen.
|
kleinerChemiker
Here to stay
|
also imho sind sessions genauso leicht wie cookies, wenn nicht sogar leichter. und vor allem, wenn cookies im browser deaktiviert sind, ist das egal, da sich darum eh php kümmert (sofern transsid aktiviert ist, was aber meistens eh ist)
am anfang des files ein session_start() und dann für variablen, die erhalten bleiben sollen einfach $_SESSION['varname'] nehmen. ist doch noch einfacher, als mit cookies, die ich ja zwangsweise immer vor der ersten ausgabe setzen muß. session-vars kann ich immer setzten.
MIK
|
Geigerzeiger
Addicted
|
aber was ist jetz der genaue unterschied zw. cookies und sessions? wie man sie im code verwendet ist mir mitlerweile eh klar.
|
kleinerChemiker
Here to stay
|
cookies speichern daten am pc des anwenders und sind daher leicht vom anwender manipulierbar. außerdem kann jeder das setzen von cookies verbieten -> nix wird gespeichert
sessions speichern die daten am server, sind daher nicht zu verändern (wenn richtig gecodet). jede session hat einenen eindeutigen id (z.b.: 9a4d93b6de69a986f7016bc425531e5). diese id kann nun von einer seite zu nächsten entweder mittels cookie oder als teil der url weitergegeben werden. ist bei php transsid aktiviert (Was meistens der fall ist) dann mußt du dich nicht drum kümmern, ob der user cookies aktiviert hat oder nicht. hat er cookies deaktiviert, wird die sid (=session-id) automatisch als teil des links weitergegeben, hat er cookies aktiviert, wird die sid als cookie weitergegeben.
session würde ich für daten verwenden, die nur für diese eine sitzung relevant sind. (z.b.: ob user eingeloggt ist oder nicht, seit wann er im forum unterwegs ist, ...)
cookies für daten, die auch nach einer session noch interessant sind (z.b.: automatisch einloggen bei jedem besuch eines forums)
hth
MIK
|
Hakke
Little Overclocker
|
Wtf? Wo ist der Sinn? Genau das machen die PHP Sessions automatisch. Wenn er dann nochmal Cookies fuer andere Dingen verwenden moechte, ist das auch voelleig OK. Ja, aber ned für autologins zum Bleistift. Jedenfalls wäre mir keine Lösung bekannt, falls aber jemand eine kennt, bitte her damit. Ich zB übergebe beim Login einige Daten (verschlüsselt), die ich lieber mit nem Cookie setze. Wenn aber jemand eben keine Cookies annimmt, setze ichs halt temporär in einer Session und hole die Infos aus der DB, und schreibe die neuen rein. Mit ner lahmen db Anbindung spare ich mit der Cookievariante noch Zeit und db-Traffic. LG, Flo
|
funka
Legend
ex-prophet(down below)
|
sorry aber deine aussage ist sehr schwammig
sessionscontainer machst du nur bei sehr grossen plattform unabhaengigen projekten als db
es macht keinen sinn sachen wie "is_authorized" vom client schicken zu lassen oder staendig username und pass neu mitzuschicken (sniffing helloworld)
ein cookie afair ist nichts anderes als ein haufen extra headers die der browser _immer_ mitschickt
es ist sicher nicht schneller eine zeile text uebers internet zu schicken anstatt sie von einer lokalen platte (auch wenns in einer isam db gekapselt ist) zu lesen
das einzige wo cookies wirklich sinn machen sind persistente informationen wie eben uva zb autologin, warenkorb nicht registrierter oder user verhalten erfassen - da hat rektal einfach recht
|
Hakke
Little Overclocker
|
Na, soviel is schon klar. User/Loginsensitive Sachen (ausser autologin), also alles was den Useraccount bzgl seiner privaten Daten betrifft gehen selbstverstöndlich nicht über einen Cookie. Eher Sachen wie ob er aktiviert ist, wann der letzte Login war, etc. Sowas erfahr ich halt bei Cookie.Verweigerern nicht so einfach, aber bei denen aktualisier ich halt eine Tabelle, wenn kein Cookie gefunden wird. Dasselbe, wenn jemand seine Cookies löscht. Beim nächsten Login wird ein Wert in die Tabelle geschrieben, und gut is.
So meinte ich das mit der Abfrage, ob Cookies verwendet werden oder nicht. Wollte das Beispiel ja nur anbringen, weil ja am Anfang nicht dastand, wozu genau er den Cookie verwenden will.
LG, FLo
|
Rektal
Here to stay
|
Passend zum Thema, schlechtester Einsatz von Cookies: http://www.hartlauer.at/ . Wer Cookies nicht aktiviert hat, kann die Seite nicht einmal normal be-surfen. Hier hat es die Entwicklung eindeutig zu gut gemeint und ueber das Ziel hinausgeschossen, den Sinn von Cookies und deren Einsatz nicht verstanden.
|
Rektal
Here to stay
|
Hoeh, Update: zufaellig mal hartlauer.at angesurft. Na sowas, setzt keine Cookies mehr vorraus :-)
|
Anmeldung