[PHP] Session blijft niet geset na redirecten

[Anoniem: 419509]

Hallo,

Ik heb een simpel inlogscriptje dat de gebruikersnaam en het wachtwoord controleert. Als deze gegevens juist zijn wordt er een session geset en vervolgens wordt doorverwezen naar een menu (een andere file). Hier controleer ik of de session geset is. zo ja, dan wordt het menu weergegeven. is de session niet geset, dan wordt je terugverwezen naar het inlogform. Dat is de theorie. De praktijk is dat in file 1 (inlogpagina) de session wel geset wordt, maar als file 2 (het menu) erop controleert de session ineens niet bestaat en vervolgens terugstuurt naar de inlogpagina.

inlogform.php:

code:

if($_POST['username'] = "user" && $_POST['password'] = "pass"){ //controleer username en password
            $_SESSION['login'] = true; //session wordt geset
            ?><script type="text/javascript">self.location.href = "menu.php";</script><?php //redirect naar menu
}

menu.php

code:

if(!isset($_SESSION['login'])){ //als session NIET geset is, redirecten
           ?><script type="text/javascript">self.location.href="inlogform.php"</script><?php
}
else{
           //menu weergeven

De vraag: Hoe kan het dat die session ineens niet meer bestaat en hoe kan ik het oplossen?

Note: in beide bestanden staat session_start() bovenaan
Note 2: Toen ik dit op usbwebserver testte werkte het wel goed. op het grote boze web treedt dit probleem op.

[PatrickH89]

Even los van dit probleem: redirecten doen we natuurlijk met header(), dat is een stuk netter dan een Javascript redirect (als dat niet noodzakelijk is).

[Emgeebee]

Je weet zeker dat authenticatie van het wachtwoord en de gebruikersnaam goed gaat?

[Anoniem: 419509]

@PatrickH89 Sorry Wel met header() geprobeerd, maar helpt niet. Ga denk ik binnenkort maar eens js redirect door headers vervangen.
@Michielgb Ja dat weet ik zeker. Ik heb gecontroleerd of de session geset wordt en dat is zo. Het vreemde is dus dat hij ineens niet meer bestaat na redirecten.

[Qck]

Moet

code:

if($_POST['username'] = "user" && $_POST['password'] = "pass"){

niet

code:

if($_POST['username'] == "user" && $_POST['password'] == "pass"){

zijn?

[ReenL]

In een ongunstig geval wordt het javascriptje sneller geladen in de browser dan dat je php script draait op de server. Pas aan het einde van je script wordt de sessie weggeschreven. Dus je hebt een race condition.

Voorbeeld:

PHP:

<?php
session_start();
$_SESSION['value'] = 'test';
echo '<script type="text/javascript">self.location.href="script2.php"</script>';
flush();
sleep(5);

script2.php:

PHP:

<?php 
session_start();
print_r($_SESSION);

[Ellos]

doe ook maar meteen === ipv ==

blijven grote gaten aanwezig als je het niet doet, waaronder deze mooie.
password:
"+0.1"==".1" geeft true

gelukkig geeft
"+0.1"===".1"
mooi false

@hierboven

ReenL schreef op zondag 09 september 2012 @ 22:15:
etc
Dus je hebt een race condition.
etc

[Voor 33% gewijzigd door Ellos op 09-09-2012 22:18]

[Anoniem: 419509]

@Qck & Ellos: Tikfoutje van mij in dit topic. mijn daadwerkelijke code vergelijkt met gegevens uit een database. Ga er maar van uit dat die regel klopt.

@ReenL: Heb jouw voorbeeldje even uitgeprobeerd. Er wordt niks geprint.

[Emgeebee]

Het enige wat ik nog kan bedenken is dat de sessie wordt gestart op http://jouwsite.nl en vervolgens redirect naar http://www.jouwsite.nl.

[Anoniem: 419509]

Heb even gekeken. Daar zit het hem ook niet in...

[Noodels]

Staat er wel in alle files wel een session_start();

[Anoniem: 419509]

Note: in beide bestanden staat session_start() bovenaan

Ja.

[Matis]

Installeer firebug en kijk wat hij met de sessievariabelen doet. Zet error_reporting op -1 en ini_set display_errors op '1'.

Happy debugging!

[Gomez12]

Kijk eens met firebug oid of de sessie-cookie wel ontvangen wordt door de browser en of die bij de volgende request wel gestuurd wordt...

[8088]

Anoniem: 419509 schreef op zondag 09 september 2012 @ 21:02:
Note 2: Toen ik dit op usbwebserver testte werkte het wel goed. op het grote boze web treedt dit probleem op.

Wat is er anders? PHP versie, php.ini, server configuratie?
Heb je je cache al eens geleegd en cookies weggegooid? Andere browsers geprobeerd? Minimale testcase geprobeerd?

ReenL schreef op zondag 09 september 2012 @ 22:15:
Dus je hebt een raise condition.

Wordt niet eerst alle PHP code uitgevoerd voordat er ook maar enige output plaatsvindt?

[Gomez12]

8088 schreef op zondag 09 september 2012 @ 23:37:
[...]
Wordt niet eerst alle PHP code uitgevoerd wordt voordat er ook maar enige output plaatsvindt?

Mits je niet aan output-caching doet en je de juiste php-module gebruikt wordt alles gewoon as fast as possible over het lijntje gegooid.

Probeer eens een header commando onder aan je php-script te zetten en je weet of jouw server ingesteld staat op as fast as possible (error/warning) of dat hij alle output verzamelt (header wordt gehoorzaamd).

In een daadwerkelijke server-omgeving wordt het iets complexer (gzip gaat bijv niet elke bit proberen te zippen, die gaat bufferen. Een browser buffert ook weer de inkomende bits voordat die deze gaat renderen etc. etc.) maar in principe stuurt een php-script direct de output.

[C0rnelis]

Werkt het wel wanneer je handmatig de session id toevoegt aan je URL?

PHP:

header('location: /test/?' . session_name() . '=' . session_id());

Als dit wel werkt heeft de server mogelijk een andere settings dan jouw testmachine voor http://www.php.net/manual...ini.session.use-trans-sid (als ik het goed heb begrepen)

[Voor 46% gewijzigd door C0rnelis op 10-09-2012 00:13]

[jeepey]

Ik had dit probleem laatst ook, uiteindelijk zat voor mij het probleem in de session.save_path instelling van php. Deze verwees naar een directory waar apache geen schrijfrechten op had. De sessie-variabelen konden daardoor niet worden opgeslagen en gingen verloren bij iedere beëindiging van het script.

*snip*

[Voor 10% gewijzigd door Creepy op 10-09-2012 11:57]

[Anoniem: 419509]

@8088: Ik heb verschillende browsers op verschillende computers geprobeerd en cache/cookies leeggegooid. Hielp niet.

@C0rnelis: Geprobeerd. zelfde probleem.

@jeepey: HELD het lijkt nu te werken. het enige probleem is dat ik deze melding krijg:
Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /blahblahndex.php:3) in /blahblah/index.php on line 5

Eerste paar regels van die file:

code:

<!DOCTYPE html>

<?php
    session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));
    session_start();

Nu kan ik natuurlijk gewoon die meldingen uitzetten, maar dat zorgt er alleen maar voor dat ik de melding niet meer ZIE. Iemand een idee hoe ik het op moet lossen?

[Kosty]

Voor je session_start() kan je geen output hebben. Dus, zet die PHP code boven je doctype en alles komt goed .

[NMe]

Had je die laatste melding überhaupt al eens in Google gestopt voordat je het hier vroeg?

[Anoniem: 419509]

@ NMe: Ging net zo lekker hier, denk ga gewoon door

Ken de melding en weet wat hij betekent. Dacht dat het kwam doordat

session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../session'));
boven de session_start() stond en volgens php.net kon dat niet anders. Dus daarom vroeg ik hier om verdere hulp.

Ik ga er even mee aan de slag.

EDIT: Doctype regel naar beneden schuiven lost het brobleem op. Allen bedankt voor de hulp!

[Voor 11% gewijzigd door Anoniem: 419509 op 10-09-2012 20:52]

[ZeroXT]

ReenL schreef op zondag 09 september 2012 @ 22:15:
In een ongunstig geval wordt het javascriptje sneller geladen in de browser dan dat je php script draait op de server. Pas aan het einde van je script wordt de sessie weggeschreven. Dus je hebt een raise condition.

Voorbeeld:

PHP:

<?php
session_start();
$_SESSION['value'] = 'test';
echo '<script type="text/javascript">self.location.href="script2.php"</script>';
flush();
sleep(5);

script2.php:

PHP:

<?php 
session_start();
print_r($_SESSION);

Van wie heb je dit nu weer geleerd?

De eerste pagina zal controleren op authenticatie en zodra dit positief is zal er een script tag terug worden verstuurd naar de client. Vervolgens wordt de client doorverwezen middels Javascript naar een andere pagina. Hoe kom je er bij dat hier een raise (officieel race) condition van toepassing is? De client krijgt niet eerder de scripttag terug dan wanneer PHP klaar is, of je er nu geen sleep of een sleep van 30 sec. in zet. Dus waarom zou je er überhaupt een flush in willen zetten, dat zou het script juist niet ten goede komen.

Overigens is de manier van opbouw in dit script niet helemaal geweldig maar dat terzijde.

[Voor 11% gewijzigd door ZeroXT op 11-09-2012 01:13]

[Gomez12]

ZeroXT schreef op dinsdag 11 september 2012 @ 01:06:
[...]
De client krijgt niet eerder de scripttag terug dan wanneer PHP klaar is

Onwaar.

[Anoniem: 241683]

Gomez12 schreef op dinsdag 11 september 2012 @ 07:41:
[...]

Onwaar.

Eensch: http://nl3.php.net/flush en lees dan vooral:

Flushes the write buffers of PHP and whatever backend PHP is using (CGI, a web server, etc). This attempts to push current output all the way to the browser with a few caveats.

[NMe]

Dat betekent dat de flush nodig is. De sleep slaat echter nergens op, bij mijn weten. Op het moment dat je al ge-echo'd hebt is de sessie sowieso al afgehandeld namelijk.

[Voor 33% gewijzigd door NMe op 11-09-2012 22:26]

[Gomez12]

NMe schreef op dinsdag 11 september 2012 @ 22:25:
Dat betekent dat de flush nodig is. De sleep slaat echter nergens op, bij mijn weten. Op het moment dat je al ge-echo'd hebt is de sessie sowieso al afgehandeld namelijk.

Als ik het goed begrijp is de sleep maar een voorbeeldje.

Genoeg real-live voorbeelden gezien waar ipv sleep er meerdere lange query's stonden, lange query's werden per stuk uitgevoerd, tussen de query's door werd er een (ik meen 255 tekens vanwege IE) html-code naar de client gestuurd zodat die voortgang zag.

Poor man's progress bar en gelijk het probleem geelimineerd dat je browser een timeout geeft omdat er 1000 query's serieel worden gedraaid a 1 seconde per stuk.

[ReenL]

Van wie heb je dit nu weer geleerd?

Constructief... Als je problemen hebt met mijn antwoorden op dit forum, ik ben beschikbaar over PM.

De eerste pagina zal controleren op authenticatie en zodra dit positief is zal er een script tag terug worden verstuurd naar de client.

Correct, echter is het voorbeeld code, weet jij of er daarna nog iets gebeurt?

Vervolgens wordt de client doorverwezen middels Javascript naar een andere pagina. Hoe kom je er bij dat hier een race condition van toepassing is?

Omdat output buffering uit kan staan in php. Het javascriptje gebruikt geen window.onload of iets dergelijks dus wordt direct uitgevoerd zodra deze aankomt op de client.

De client krijgt niet eerder de scripttag terug dan wanneer PHP klaar is, of je er nu geen sleep of een sleep van 30 sec. in zet.

Dat is dus een verkeerde aanname. Of anders gezegd en ik citeer "Van wie heb je dit nou weer geleerd? "

Dus waarom zou je er überhaupt een flush in willen zetten, dat zou het script juist niet ten goede komen.

Om outputbuffering = off te simuleren. Ik wil daar geen flush zetten en ik wil al helemaal niet javascript gebruiken voor redirects. Dit was de versimpelde versie, van wat er mis kan zijn met de code, die de TS gegeven heeft.

offtopic:
Ook gebruik ik over het algemeen geen sleep

@ReenL: Heb jouw voorbeeldje even uitgeprobeerd. Er wordt niks geprint.

Lees mijn bericht, dat is een versimpelt voorbeeld van wat er MISSCHIEN _{voordat we weer rants krijgen} mis kan zijn met je script. Niet de oplossing voor het probleem. Bij jou is de sessie ook niet beschikbaar op de tweede pagina en ik gok, met de beperkte informatie die ik van je krijg, dat dit het probleem is.

Als ik het goed begrijp is de sleep maar een voorbeeldje.

Dank je voor het lezen, blijkbaar is het woord "Voorbeeld" boven de code niet duidelijk genoeg.

[ZeroXT]

Gomez12 schreef op dinsdag 11 september 2012 @ 07:41:
[...]

Onwaar.

Anoniem: 241683 schreef op dinsdag 11 september 2012 @ 21:33:
[...]


Eensch: http://nl3.php.net/flush en lees dan vooral:

[...]

ReenL schreef op woensdag 12 september 2012 @ 08:55:
[...]

Constructief... Als je problemen hebt met mijn antwoorden op dit forum, ik ben beschikbaar over PM.


[...]

Correct, echter is het voorbeeld code, weet jij of er daarna nog iets gebeurt?


[...]

Omdat output buffering uit kan staan in php. Het javascriptje gebruikt geen window.onload of iets dergelijks dus wordt direct uitgevoerd zodra deze aankomt op de client.


[...]

Dat is dus een verkeerde aanname. Of anders gezegd en ik citeer "Van wie heb je dit nou weer geleerd? "


[...]

Om outputbuffering = off te simuleren. Ik wil daar geen flush zetten en ik wil al helemaal niet javascript gebruiken voor redirects. Dit was de versimpelde versie, van wat er mis kan zijn met de code, die de TS gegeven heeft.

offtopic:
Ook gebruik ik over het algemeen geen sleep

Blijkbaar heb ik mezelf verkeerd verwoord aangezien jullie drie me niet begrijpen.

Dus waarom zou je er überhaupt een flush in willen zetten, dat zou het script juist niet ten goede komen.

Ik bedoelde juist hiermee dat je met een flush dit soort problemen gaat veroorzaken.

[ReenL]

Ik bedoelde juist hiermee dat je met een flush dit soort problemen gaat veroorzaken.

offtopic:
En daarmee heb je dus niets aan de discussie toegevoegd, niemand zegt dat je flush moet gebruiken.

Het was voorbeeld code om output buffering = off te simuleren.

[Gomez12]

ZeroXT schreef op woensdag 12 september 2012 @ 15:17:
[...]
Blijkbaar heb ik mezelf verkeerd verwoord aangezien jullie drie me niet begrijpen.
[...]
Ik bedoelde juist hiermee dat je met een flush dit soort problemen gaat veroorzaken.

Flush versnelt slechts het aantonen van dit probleem. Elk php-script waarvoor niet 100% gegarandeerd geregeld is dat er output buffering in gebruik is kan dit ondervinden.

Een snelle client op een snelle verbinding en je kan dezelfde problemen krijgen.

Fix je het probleem dan maakt een flush niet meer uit.

Probeer je enkel maar geen flush te gebruiken dan blijft het probleem en is het enkel maar wachten tot het op gaat treden.