Cookies in PHP? - Seite 2

Seite 2 von 2 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/cookies_in_php_105502/page_2 - zur Vollversion wechseln!

dio schrieb am 29.01.2004 um 12:27

Zitat von Rektal
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 schrieb am 29.01.2004 um 12:39

Seh ich anders Wenn der Thread-Starter gleich in die Wiege mitbekommt wie mans richtig umsetzt ist ihm eher geholfen.

dio schrieb am 29.01.2004 um 13:10

Zitat von Rektal
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 schrieb am 29.01.2004 um 13:18

Dazu hab ich auch eine Meinung: dann soll er hier fragen, hier wird ihm Kompetent (wer lacht da? setzen!) geholfen.

kleinerChemiker schrieb am 29.01.2004 um 13:45

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 schrieb am 29.01.2004 um 15:54

aber was ist jetz der genaue unterschied zw. cookies und sessions? wie man sie im code verwendet ist mir mitlerweile eh klar.

kleinerChemiker schrieb am 29.01.2004 um 16:05

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 schrieb am 31.01.2004 um 14:50

Zitat von Rektal
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 schrieb am 31.01.2004 um 20:24

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 schrieb am 01.02.2004 um 12:28

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 schrieb am 02.02.2004 um 15:53

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 schrieb am 10.07.2004 um 08:26

Hoeh, Update: zufaellig mal hartlauer.at angesurft. Na sowas, setzt keine Cookies mehr vorraus :-)