[php]Krijg cookies niet werkend

[Verwijderd]

Ik snap er niks meer van.

Ik wilde een cookie maken maar om 1 of andere zeer onduidelijke reden werkt dit niet.

Ik haal eerst waardes uit een DB en die wil ik vervolgens in een cookie zetten
Ik heb een function gemaakt genaamd: makecookie

code:

function makecookie($gebruikersnaam, $user_id, $loggedin, $emailadres, $user_taal, $is_admin, $adminlevel, $password) {
    $info = base64_encode("$user_id:$gebruikersnaam:$loggedin:$emailadres:$user_taal:$is_admin:$adminlevel:$password");
    setcookie("user","$info",time()+2592000);
}

Vervolgens nadat ik de de gegevens uit de DB heb gehaald doe ik:

code:

makecookie($gebruikersnaam, $user_id, $loggedin, $emailadres, $user_taal, $is_admin, $adminlevel, $passwordmd);

Maar het resultaat is niks, nada...
Er wordt geen cookie gemaakt (niet aanwezig op de pc)
Nu heb ik waar dat makecookie doe een heel simpele cookie functie gezet:
setcookie("gebruikersnaam", $gebruikersnaam, time()+3600);

En zelfs dit werkt niet!
Ook hier wordt geen cookie gemaakt.

Nu dacht ik dat ligt aan mijn browser, maar nee ook met een andere browser (IE en FF) werkt het niet, een andere website die op dezelfde server staat met cookies (ook zelf gemaakt) werkt wel normaal.

Ik snap er echt niks meer van, volgens de PHP.net website moet de pagina eerst herladen worden, nu als ik ergens op klik na maken van de cookie is er nog steeds geen cookie aanwezig.
Heb in het verleden wel eens vaker met cookies gewerkt maar nooit dit probleem gehad.

Waar kan dit in godsnaam aan liggen?

Ohja, de cookies worden in een function opgeroepen en via een andere function gemaakt.( is voor een login script)

[Verwijderd]

Weet je zeker dat je nog geen ouptut ervoor hebt gehad (zet setcookie anders in een if-constructie)

[Bosmonster]

Goeie cookie ook, met username, password, adminlevel en de hele reutemeteut... Wees blij dat het niet werkt

[ Voor 18% gewijzigd door Bosmonster op 06-09-2005 13:39 ]

[Room42]

Precies. Doe even

PHP:

error_reporting( E_ALL );
if (!setcookie("user","$info",time()+2592000)) {
   echo "Alé, ik kan dat verdomde cookie niet zetten!"; // Leuk, met belgisch accent voor het effect. :+
} else {
   echo "Oh, dat ging best goed!";
}

Of had je error_reporting( E_ALL ) al geprobeerd?

Bosmonster: +4 inzichtvol, intressant, behulpzaam, grappig

[ Voor 17% gewijzigd door Room42 op 06-09-2005 13:43 ]

[SWINX]

doe eens $result = setcookie(....);
echo (int)$result;

Krijg je dan 0 of 1 ?

En inderdaad wat Bosmonster zegt, het is zwaar onveilig om op deze manier je gegevens in een cookie op te slaan, sla liever een sessie-id op, die daarna de gegevens uit de DB haalt.

[TRON]

Met Bosmonster ^^


Zorg dat je er een sessie_id inzet en dan ben je al een stuk veiliger en slimmer bezig.

[Verwijderd]

Ik had eerst een login systeem met alleen sessies, maar elke keer als de browser is afgesloten ben je uitgelogged, zwaar onhandig.
Daarom wilde ik het omzetten naar cookies.

Zodra de cookies werken wilde ik het finetunen en gedeeltes weer in sessies zetten, echter dan zal het eerst moeten werken.

Ik ga nu even de voorgestelde dingen doen.

OK de error:

Warning: Cannot modify header information - headers already sent by (output started at e:\webserver\www\website2\functies.php:225) in e:\webserver\www\website2\hoofdbestand.php on line 12

Wat staat er op line 12:

code:

if (!setcookie("user","$info",time()+2592000)) {

Zodra ik een setcookie doe, maakt niet uit waar krijg ik dezelfde error......
Het vreemde is dat ik nergens anders cookies gebruik dus hoe komt die erbij dat die al zijn verzonden.

[ Voor 42% gewijzigd door Verwijderd op 06-09-2005 14:14 ]

[japaveh]

Je mag geen enkele output naar de browser sturen voordat de cookie geset wordt, let dus eventjes op echo of printstatussen en of er geen spaties oid voor je <?php staan.

[Verwijderd]

Zover ik weet ik dat ook niet het geval, ik wordt hier echt knetter van

[SWINX]

niet alleen voor de <?php
het gaat hier om de functies.php zoals de melding al zegt
daar schijnt in regel 225 al wat output te staan.
En dat mag dus niet als je een cookie wilt gaan setten...

[Room42]

Verwijderd schreef op dinsdag 06 september 2005 @ 14:09:
Het vreemde is dat ik nergens anders cookies gebruik dus hoe komt die erbij dat die al zijn verzonden.

Hier intepreteer je de foutmelding een beetje verkeerd. De melding dat de headers al verstuurd zijn ontstaat doordat er output (html of wat dan ook. Een spatie is voldoende) naar de browser is gestuurd.
Hierna is het sturen van extra headers (waar cookies ook deel van uitmaken) niet meer mogelijk.

Zoals SWINX al zegt; controleer functies.php, regel 255. Daar zou al output gegenereerd moeten worden. Dat moet je dus voorkomen of bufferen.

[ Voor 15% gewijzigd door Room42 op 06-09-2005 15:06 ]

[mosymuis]

Verwijderd schreef op dinsdag 06 september 2005 @ 14:09:
Ik had eerst een login systeem met alleen sessies, maar elke keer als de browser is afgesloten ben je uitgelogged, zwaar onhandig.
Daarom wilde ik het omzetten naar cookies.

TRON bedoelt dat je dan dus sessie_id's in je cookie opslaat, in plaats van al die gegevens die je er nu in zet.

Wat betreft de header fout: het is inderdaad zo dat er iets wordt verzonden, maar dit hoeft geen probleem te zijn.

[ Voor 9% gewijzigd door mosymuis op 06-09-2005 15:06 ]

[Verwijderd]

wat wel veiliger is is de gebruiksnaam en een md5 wachtwoord in het koekje zetten.

Zodra een gebruiker dan terug komt kan je zijn gebruikersgegevens weer ophalen uit de database. Hiervoor kan je de MD5 functie gebruiken van mysql
dus zoites als dit

PHP:

$query = "SELECT * FROM users WHERE username = '". $_COOKIE['username'] ."' AND MD5(pass ) = '". $_COOKIE['pass'] ."'";

$result = mysql_query($query);

$currentUsr = mysql_fetch_assoc($result);

Ik heb trouwens geen idee of je de MD5 functie op die plek mag gebruiken. De meeste grote sites, zoals waarschijnlijk ook deze, slaan wachtwoorden op met een md5 hash.

//update:
Ik heb ff gekeken, die query mag dus. Maar ik denk wel dat de query langzamer wordt naarmate je meer gebruikers hebt. Bij 100 ofzo maakt het niet veel uit (denk ik)

[ Voor 25% gewijzigd door Verwijderd op 06-09-2005 15:19 ]

[AW_Bos]

Verwijderd schreef op dinsdag 06 september 2005 @ 15:15:
wat wel veiliger is is de gebruiksnaam en een md5 wachtwoord in het koekje zetten.
...

Sorry mar dat is niet echt bepaald veilig. In een cookie hoort alleen een hasj te staan van de inlogsessie.

[Bosmonster]

Waarom het wachtwoord, zelfs in MD5, in de cookie zetten? Als je de cookie jat ben je toch wel ingelogd, dus als je al zo bezig bent is alleen de username/userID voldoende.

Als je het nog enigszins veilig wil hebben, sla dan bijvoorbeeld IP op bij de sessie en alleen het sessie ID in de cookie. Klopt het IP niet meer met de sessie, dan is de kans redelijk dat de cookie geript is.

Bijkomend voordeel is dat je gebruikers kunt laten zien vanaf waar ze allemaal ingelogd zijn en of dit wel klopt. Zo niet dan kunnen ze zelf de sessies beeindigen en/of hun wachtwoord wijzigen.

GoT werkt ook op een dergelijke manier.

[ Voor 24% gewijzigd door Bosmonster op 06-09-2005 15:22 ]

[Verwijderd]

Als je de cookie jat ben je toch wel ingelogd, dus als je al zo bezig bent is alleen de username/userID voldoende.

Dat slaat natuurlijk nergens op.

De meeste forums maken gewoon gebruik van usernaam/userid icm wachtwoord, of een een of andere gegenereerde hashcode, of sessie.

Hoe dan ook, als je het koekje te pakken krijgt, waar dit instaat dan kan je altijd inloggen. Het maakt dus niet uit wat je gebruikt.

Als je het echt veilig wilt hebben moet je idd gaan werken met een gegenereerde hash icm met ip.

Volgens mij ben je een knappe jongen als je uit de md5 hash het wachtwoord kan terughalen.

[ Voor 69% gewijzigd door Verwijderd op 06-09-2005 15:27 ]

[Bosmonster]

Verwijderd schreef op dinsdag 06 september 2005 @ 15:22:
Net of een hash van de inlogsessie veiliger is.

Volgens mij ben je een knappe jongen als je uit de md5 hash het wachtwoord kan terughalen. Trouwens je kan beter gebruikersid gebruiken ipv gebruikersnaam

Met de rekenkracht van tegenwoordig schijnt het niet al te lang te duren om bij een md5 hash een juiste string te vinden. Dat dit niet het wachtwoord is boeit niet zo, het werkt. Wachtwoorden gebaseerd op md5 zijn dus eigenlijk heel onhandig en onveilig, want ongemerkt creeer je honderden of duizenden mogelijke wachtwoorden.

Maar goed.. waar het dus om gaat is dat als je userID al in de cookie zet, het compleet overbodig is daar ook nog eens het wachtwoord, in wat voor vorm dan ook, in te zetten.

[ Voor 13% gewijzigd door Bosmonster op 06-09-2005 15:25 ]

[mosymuis]

Verwijderd schreef op dinsdag 06 september 2005 @ 15:15:

PHP:

$query = "SELECT * FROM users WHERE username = '". $_COOKIE['username'] ."' AND MD5(pass ) = '". $_COOKIE['pass'] ."'";

Ik heb ff gekeken, die query mag dus.

De query op zich wel, maar ik hoop dat hij bij niemand zal werken. Het is hoogst onverantwoord, en onnodig, om ongecodeerde wachtwoorden op te slaan in je database.

[Verwijderd]

mosymuis schreef op dinsdag 06 september 2005 @ 15:29:
[...]

De query op zich wel, maar ik hoop dat hij bij niemand zal werken. Het is hoogst onverantwoord, en onnodig, om ongecodeerde wachtwoorden op te slaan in je database.

Daarom zeg ik ook dat je wachtwoorden met md5 moet opslaan

Wachtwoorden gebaseerd op md5 zijn dus eigenlijk heel onhandig en onveilig, want ongemerkt creeer je honderden of duizenden mogelijke wachtwoorden.

Dat is misschien wat overdreven, maar je hebt wel gelijk.

Maar goed.. waar het dus om gaat is dat als je userID al in de cookie zet, het compleet overbodig is daar ook nog eens het wachtwoord, in wat voor vorm dan ook, in te zetten.

Ik kan zo achter je userid komen, daarvoor heb ik je koekje niet nodig. Je wachtwoord is wat anders. Ik snap niet goed wat je hiermee bedoelt.

Voor een site voor eigen gebruik is dit veilig genoeg. vind ik dan.

Hier wat leuke sites:
http://passcracking.com/
http://md5.crysm.net/

md5: f3789b3c1be47758203f9e8a4d8c6a2a

update:
Waar we het iig wel allemaal over eens kunnen zijn is dat "isadmin" en "adminlevel" niet in een koekje thuis horen.

[ Voor 9% gewijzigd door Verwijderd op 06-09-2005 15:53 ]

[Verwijderd]

OK, ik snap dit allemaal dat het niet in een cookie hoort.
Zoals ik al zei, het login gedeelte was al gereed maar geheel op sessions gemaakt.
Helaas kwam ik erachter dat dit niet echt handig was omdat zedroa je de browser afsluit je uitgelogged was.

De opzet was om dit "even snel" te veranderen in cookies en daarna gedeeltes die onveilig zijn in sessions te doen.

Maargoed het lukt me simpelwel niet om een cookie te saven, er zou iets worden gepost voor de cookie, kan allen niet vinden want.
De error verwijsd naar een lijn in de functie.php maar op die lijn staat alleen: }
In functies.php staan alleen maar functions vermeld, geen ech, print of wat dan ook.

Dus ik snap niet hoe er iets gepost kan worden voor die cookies, dat is namelijk de eerste functie die wordt aangesproken na de submit knop.

[SWINX]

wat dacht je van een cookie/session combi?
een cookie die een soort id bijhoud en elke keer de sessie weer netjes kan vullen.
voor de veiligheid kan je de hash in het cookie daarna ook weer vernieuwen

Post eens regels 215 t/m 235 van je functies.php

[ Voor 19% gewijzigd door SWINX op 06-09-2005 18:54 . Reden: functies.php.. whatever :P ]

[Verwijderd]

Ok, ik begin bij regel 215 en stop bij 235

code:

}

function tijdsprong ($page, $wachttijd) {
echo "<script language=\"Javascript\" type=\"text/javascript\">
    function gotoThread() {
    window.location.href='$page';
    }
    window.setTimeout('gotoThread()', $wachttijd);
</script>";
}

/*
echo "
<script language=\"javascript\">
function popuprestart(waar){
          window.open(waar,'info', 'width=450,height=300,toolbar=no,scrollbars=no,resizable=no,menubar=no,titlebar=no,status=no');
}
function popupnotitie(waar){
          window.open(waar,'$randomWHA', 'width=320,height=250,scrollbars=no,resizable=no,menubar=no');
}
function popupvraag(waar){

Zoals je kan zien is vanaf regel 226 alles uit gemarkeerd /*
Dit tot en met het einde */ ?> niet natuurlijk.

[ Voor 18% gewijzigd door Verwijderd op 06-09-2005 22:02 ]

[Radiant]

Verwijderd schreef op dinsdag 06 september 2005 @ 18:42:
OK, ik snap dit allemaal dat het niet in een cookie hoort.
Zoals ik al zei, het login gedeelte was al gereed maar geheel op sessions gemaakt.
Helaas kwam ik erachter dat dit niet echt handig was omdat zedroa je de browser afsluit je uitgelogged was.

http://nl2.php.net/manual...ion-set-cookie-params.php

Het is iig veiliger dan dat ik mijn cookie even decode en even de admin vlag op 1 zet en gelijk admin rechten heb.

[ Voor 13% gewijzigd door Radiant op 06-09-2005 22:07 ]

[SWINX]

staat na je ?> toevallig geen enter ofzo?
het moet iets simpels zijn vrees ik...

[Verwijderd]

SWINX schreef op dinsdag 06 september 2005 @ 22:50:
staat na je ?> toevallig geen enter ofzo?
het moet iets simpels zijn vrees ik...

Nee niks, ik snap het echt niet meer, ik omschrijf even de opbouw:

Index.php -->
Eerste commando is "include_once ("hoofdbestand.php");", dit is het bestand waar alle functions in staan, ook de cookie functie's (functies.php heb ik nu in dit hoofd bestand verwerkt
In dit bestand staan dus alleen function ( bla bla) commando's

Dan laad ie de menu's van de site

Dan laad ie de header van de template (hierin krijg ik dus weer die error van: output started at)
Dan wordt de inhoud geladen (van main field)
Dan wordt de footer geladen

Einde index.php


Nou vraag ik me dus af hoe het kan dat de site dus eerst de header laad en dan pas de functie's, want dat gebeurd er blijkbaar
De include voor het hoofdbestand staat echt als allereerste commando...

Ik ben echt radeloos, snap er niks meer van

[ Voor 7% gewijzigd door Verwijderd op 07-09-2005 22:30 ]

[mosymuis]

Verwijderd schreef op dinsdag 06 september 2005 @ 15:22:
[...]

Hoe dan ook, als je het koekje te pakken krijgt, waar dit instaat dan kan je altijd inloggen. Het maakt dus niet uit wat je gebruikt.

Als je het echt veilig wilt hebben moet je idd gaan werken met een gegenereerde hash icm met ip.

Het kan wel degelijk; het koekje én de sessie in je database beiden voorzien van corresponderende timestamp, en deze bij elke pageview verversen. Als de cookie dan gejat wordt, is het direct waardeloos als de originele bezoeker verder surft op de site.

@B3rt, nogmaals, je headers_sent probleem is heel gemakkelijk te omzijlen. Output control is ook helemaal geen schande om te gebruiken, het maakt het je alleen maar gemakkelijker als scripter.

mosymuis schreef op dinsdag 06 september 2005 @ 15:05:
[...]
maar dit hoeft geen probleem te zijn.

[Verwijderd]

@TS, je bent er nog steeds niet uit

Heb je al geprobeerd om echo() te verwijderen in de functie die de output veroorzaakt?

[Verwijderd]

Bosmonster schreef op dinsdag 06 september 2005 @ 15:24:
[...]


Met de rekenkracht van tegenwoordig schijnt het niet al te lang te duren om bij een md5 hash een juiste string te vinden. Dat dit niet het wachtwoord is boeit niet zo, het werkt. Wachtwoorden gebaseerd op md5 zijn dus eigenlijk heel onhandig en onveilig, want ongemerkt creeer je honderden of duizenden mogelijke wachtwoorden.

Maar goed.. waar het dus om gaat is dat als je userID al in de cookie zet, het compleet overbodig is daar ook nog eens het wachtwoord, in wat voor vorm dan ook, in te zetten.

Dit is afhankelijk van de lengte van het wachtwoord, heb je wachtwoorden van minder dan 6 karakters dan is het best mogelijk om een hash te kraken.

Daarom moet je er voor zorgen dan een wachtwoord minimaal 6 karakters heeft en als extra beveiliging zou je dit kunnen doen:

PHP:

$sWachtwoord = 'geheim';

$sWachtwoord_hash = md5(md5($sWachtwoord));

Een hash van een hash dus...

[ Voor 4% gewijzigd door Verwijderd op 08-09-2005 18:52 ]

[Gomez12]

@sandstormer : Een hash van een hash kost meer servertijd. Dit is beter en sneller op te lossen door een salted hash ( voeg een extra string toe aan het wachtwoord en ga dat hashen ). Meeste sites sturen toch het wachtwoord unencrypted over de lijn ( maar hoe zwaar vrees jij dat je gesniffed wordt??? )

@TS : Volgens mij voer je nog ergens voor het setten van de cookie ( of in het setten van de cookie ) de functie tijdsprong uit. Want php kan er best 1 of 2 regels naast zitten met zijn error reporting. Of eindigt na regel 236 het bestand??? Want als het bestand niet eindigt is het zeer raar dat php ergens een fout midden in een bestand aangeeft ( en in 99% van de gevallen klopt de fout dan ook ).

En over output buffering. Het is absoluut geen schande om te gebruiken, maar gebruik het dan zinnig. Output buffering gebruiken omdat je je eigen app niet goed kan debuggen vind ik vragen om problemen... Want het is alleen maar symptoonbestrijding. Het probleem is nog steeds in je code aanwezig.

[Verwijderd]

@mosymuis:
Output control werkt niet goed, de errors zijn weg alleen er wordt nog steeds geen cookie gemaakt.

@herelam
ik kan een echo weg halen uit functie's, die zijn gewoon nodig om de betreffende functie te laten werken.

@Gomez12
Ben het met je eens, er zit een fout in die ik niet kan vinden.
Het gaat mis zodra de header geladen wordt van de site, echter de cookies zijn een function van de site en worden al eerder geladen als de header. Maar toch error ie op de header.
Ik ben uit noodzaak maar weer terug gestapt naar mijn session versie, deze werkt wel probleemloos, enige nadeel wat ik nu nog heb is dat je elke keer opnieuw moet inloggen als je de browser afsluit, dit is zeer irritant. Dit wilde ik dus oplossen met de cookies maar dat werkt dus niet.

[Verwijderd]

Gomez12 schreef op donderdag 08 september 2005 @ 21:42:
@sandstormer : Een hash van een hash kost meer servertijd. Dit is beter en sneller op te lossen door een salted hash ( voeg een extra string toe aan het wachtwoord en ga dat hashen ). Meeste sites sturen toch het wachtwoord unencrypted over de lijn ( maar hoe zwaar vrees jij dat je gesniffed wordt??? )

Liever een paar micro seconden langer wachten bij het inloggen dan gehacked worden, omdat een gebruiker een te kort wachtwoord heeft ingevoerd. Maar hoe moet ik dat zout zien een vaste string voor iedereen hetzelfde?

@TS :

Maak van alle code voor setcookie() kommentaar, krijg je nog steeds een error dan staan er tekens s buiten de php tags.

[ Voor 10% gewijzigd door Verwijderd op 08-09-2005 23:51 ]

[NMe]

Verwijderd schreef op donderdag 08 september 2005 @ 18:47:
[...]
Een hash van een hash dus...

Een hash van een hash is net zo makkelijk te bruteforcen, en aangezien meer mensen denken dat het veiliger is om dit te doen kun je er vergif op innemen dat mensen die kwaad in de zin hebben dit truukje ook kennen. Het duurt alleen wat langer.

[Glimi]

-NMe- schreef op donderdag 08 september 2005 @ 23:48:
Een hash van een hash is net zo makkelijk te bruteforcen, en aangezien meer mensen denken dat het veiliger is om dit te doen kun je er vergif op innemen dat mensen die kwaad in de zin hebben dit truukje ook kennen. Het duurt alleen wat langer.

Waarom zou het langer duren? Er is gespecificeerd dat een MD5-hash 128-bits is, dus is je input een enorm stuk geslonken. Praktisch gezien maakt het niet zoveel uit, aangezien je er bijna wel van uit kan gaan dat een password < 128-bits is (in ISO-9985-15).
Analytisch gaat trouwens toch nog een stuk sneller.

Dit betekent echter niet dat MD5 inherent onveilig is, zover ik weet blijft het zeer complex om een bericht x zo te wijzigen naar x' en er toch ervoor te blijven zorgen dat md5(x) = md5( x' )

[HawVer]

@ts

Misschien kun je hier wat mee?
http://nl3.php.net/manual/en/function.ob-start.php

Zet anders eens je bestanden online in een zippie.. Dan kunnen we er even naar kijken.

[mosymuis]

@Gomez12: Ik ben het niet met je eens dat output buffering een fout zou verdoezelen, want met buffering aan is het geen fout, aangezien alle output netjes afgevangen wordt zolang er nog header communicatie is. Het maakt het je als scripter gewoon gemakkelijker, zonder dat het consequenties heeft voor je script.

@B3rt: Dat lijkt me sterk, de cookie functies werken normaal nog net zo als wanneer ze zónder output control worden gezet. Daar doe je dus iets fout.

@Glimi: Het zou vele malen langer duren, omdat je eerst een string van 32 tekens moet bruteforcen, en vervolgens het originele wachtwoord van ~8 karakters. Dat lukt je niet op normale servers in een acceptabele tijd.

@HawVer: Dat is dus een functie uit het output control waar ik op wees.

[Gomez12]

@nme : het bruteforcen gaat net zo snel / langzaam. Maar als jij een md5 wilt bruteforcen dan wens ik je veel succes. Dan heb meer aan md5 stelen en dan rainbow tables gebruiken waar dubbele md5 en salted md5 wel mee helpt.

@TS : Als je zelfs met output buffering nog geen cookie krijgt dan gaat er gewoon iets grondig fout bij je setcookie. Gooi je er misschien een lege string in??? Echo eens je exacte output naar je scherm.

@Sandstormer : een salted md5 is inderdaad een md5 van een wachtwoord met een stukje tekst eraan toegevoegd ( theorie is dat client het stukje toegevoegde tekst niet kent dus geen correcte md5 zelf kan maken ) wat het stukje zou moeten zijn mag je zelf bepalen. Of je kan een vaste zin gebruiken ("Dit is mijn salt") of een redelijk vast iets ( huidige datum dit is alleen rond 0:00 niet constant )

@mosymous : Met buffering aan is het inderdaad geen fout, maar als ik een project maak zonder buffering en ik heb een probleem en dan pas ga ik buffering gebruiken dan vind ik het een fout verdoezelen. Als ik nou gelijk met buffering gestart was en zelfs als laatste regel output nog een header wil kunnen zetten dan is het geen verdoezelen, maar in dit geval wel imho.

Maar TS kijk eens naar je cookie parameters en bouw een test php bestandje wat eerst een standaard cookie zet en als dit lukt laat hem dan de parameters uit mysql halen. Als dit lukt dan zit de fout ergens anders in je script.

[Verwijderd]

Ik heb gevonden (eindelijk) waarom de cookies niet werken, nadat de error weg is.

Als bij mijn webserver de functie: register_globals op ON staat dan werken de cookies wel, echter zodra deze op OFF staat doen ze het niet meer.

Dit lijkt me niet normaal, daar deze functie volgens mij niets met cookies te maken heeft maar met het versturen van data naar de volgende pagina via de commando's GET en POST

Iemand een idee hoe dit te fixen is, want ik wil eigenlijk dat de site ook werkt op OFF met cookies.

[mosymuis]

Hoe haal je de cookies op? Met $_COOKIE['cookienaam'], $HTTP_COOKIE_VARS['cookienaam'] of $cookienaam? In het laatste geval is het niet meer dan logisch dat deze setting op off je script disabled. Deze converteert namelijk alle EGPCS waarden, zie: php.net. Je moet daarom altijd met superglobals werken, dat is netjes, veiliger (minder risico op lekken) en het werkt op alle configuraties.

[ Voor 20% gewijzigd door mosymuis op 27-09-2005 14:19 ]

[Verwijderd]

Op deze manier:
if (isset($_COOKIE["cookiewaarde"])) ......

In de cookie heb ik geen info staan over de user, pass etc..
Ik genereer een bepaalde code die ik in een cookie stop en in een database, zodra de bezoeker terug komt kijk ik of hij de cookie heeft en match de code in de cookie aan de database.
Als er een match is haal ik de gegevens uit de database en zet deze in een sessie, de bezoeker is dan weer ingelogged.

Ik gebruik dus de waarde in de cookie zelf niet op de site, ik controleer er alleen maar mee of de bezoeker al eens op de site is geweest en wie het dan zou moeten zijn.

EDIT:

Laat maar....
Door een heel domme fout van mij werkte het niet
Ik deed inderdaad controleren via:
if (isset($_COOKIE["cookiewaarde"])) { ... bla bla

echter in de bla bla doe ik een mysql query om de gegevens uit de database te halen wat matched aan de inhoud van de cookie.
En wat doe ik daar.....
Juist gewoon $cookiewaarde (aarrggggggg)
heb er: $cookiewaarde = $_COOKIE["cookiewaarde"];
voorgezet en probleem was opgelost.... (erg domme fout van me)

[ Voor 30% gewijzigd door Verwijderd op 27-09-2005 14:30 ]