[PHP] Session reset tijdens downloadscript

[bindsa]

Ik gebruik een downloadscript geschreven in PHP om downloads aan de client aan te bieden, maar nu wordt regelmatig tijdens downloadscript de sessie om de een of andere reden gereset, waardoor de client wordt uitgelogd. Waardoor kan dit gebeuren?

Dit is de code voor het downloadscript:

PHP:

// Download gedeelte
if (!empty($action) and $action == "download") {
    $file = rawurldecode($_GET['file']);
    if (!empty($file)) {
        $filekey_result = dbquery("SELECT filekey, filename, owner FROM leeromgeving_diskspace WHERE filename = '$file' AND owner = '$loggedinowner'");
        //Als hij de fileky niet vindt in diskspace tabel gaat het waarschijnlijk om een gedeeld bestand, zoek dan in de share tabel
        if(mysql_num_rows($filekey_result) == 0) {
            $filekey_result = dbquery("SELECT ld.filekey, ld.filename, ld.owner FROM leeromgeving_diskspace ld, leeromgeving_shares ls WHERE ld.filename = '$file' AND ls.share = '$loggedinowner' AND ls.filekey = ld.filekey");
        }
        //Als hij iets gevonden heeft, bied dat bestand dan aan de browser aan
        if(!mysql_num_rows($filekey_result) == 0) {
            list($filekey, $filename, $fileowner) = mysql_fetch_row($filekey_result);
            $location = "./userfiles/".$fileowner."/".$filekey;
            header('Content-Description: File Transfer');
            header('Content-Type: application/octet-stream');
            header("Content-Disposition: attachment; filename=\"".$filename."\";");
            header('Content-Transfer-Encoding: binary');
            header('Expires: 0');
            header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
            header('Pragma: public');
            header('Content-Length: ' . filesize($location));
            ob_clean();
            flush();
            readfile($location);
            exit();
        }
        //Niks gevonden? Geef dat netjes weer op het scherm
        else {
            print "<br><font color = 'red'><b>Het te downloaden bestand kon niet gevonden worden</b></font>";
        }
    }
}

De variabele om te kijken of iemand is ingelogd ziet er zo uit:

PHP:

$_SESSION['ingelogd'] = 1;

In de pagina waar het downloadscript zich bevind wordt als volgt gekeken of er ingelogd is:

PHP:

if ($_SESSION['ingelogd'] == 1) {
   //Pagina code staat hier
}

Het vreemde is ook dat de sessie niet altijd geleegd wordt, maar ongeveer 1 van de 2 keer.

[Snake]

Zou je astublieft je $file willen escapen. Als ik nu de naam van je tabellen ken kan ik zo heel je database wissen!

Waar is je site eigelijk gehost? Ik heb al vaker problemen gezien tussen PHP sessions en shared hosting.

[ Voor 31% gewijzigd door Snake op 24-12-2009 14:47 ]

[bindsa]

Dat wordt al gedaan door de volgende code:

PHP:

$_GET = array_map('mysql_real_escape_string', $_GET); 
$_POST = array_map('mysql_real_escape_string', $_POST); 
$_POST = array_map('htmlspecialchars', $_POST);
$_POST = array_map('strip_tags', $_POST);
$_COOKIE = array_map('mysql_real_escape_string', $_COOKIE); 
$_REQUEST = array_map('mysql_real_escape_string', $_REQUEST);

[bindsa]

Waar is je site eigelijk gehost? Ik heb al vaker problemen gezien tussen PHP sessions en shared hosting.

http://000webhost.com is de host
http://leeromgeving.comxa.com is de URL van onze site

Een betaalde host overwegen we misschien in de toekomst, maar eerst willen we de applicatie afhebben.

[Manuel]

Waar stel jij je sessie tijd in? Of gebruik je nog steeds de normale sessie tijd?
Zet dit eens bovenaan als dat werkt op die host:

PHP:

//60 * 60
ini_set("session.gc_maxlifetime", 3600);

Dit zorgt er voor dat een sessie in totaal 1 uur geldig is.

[bindsa]

Manuel schreef op donderdag 24 december 2009 @ 15:11:
Waar stel jij je sessie tijd in? Of gebruik je nog steeds de normale sessie tijd?
Zet dit eens bovenaan als dat werkt op die host:

PHP:

//60 * 60
ini_set("session.gc_maxlifetime", 3600);

Dit zorgt er voor dat een sessie in totaal 1 uur geldig is.

Dit werkt (voor zover ik kan testen) helemaal perfect. Ik gebruikte nog de standaard tijd. Wederom hartstikke bedankt Tweakers

[HuHu]

L0calh0st schreef op donderdag 24 december 2009 @ 14:47:
Dat wordt al gedaan door de volgende code:

PHP:

$_GET = array_map('mysql_real_escape_string', $_GET); 
$_POST = array_map('mysql_real_escape_string', $_POST); 
$_POST = array_map('htmlspecialchars', $_POST);
$_POST = array_map('strip_tags', $_POST);
$_COOKIE = array_map('mysql_real_escape_string', $_COOKIE); 
$_REQUEST = array_map('mysql_real_escape_string', $_REQUEST);

Dat is ook niet helemaal fantastisch. Je hoort dat gewoon te doen op het moment dat je data wordt gebruikt in een query. Of wordt getoond op het scherm. Of wordt uitgelezen door je applicatie.

Niet altijd en overal en onvoorwaardelijk.

Als je nu POST data wilt opslaan in de database, dan ziet je met bewerkte gegevens in je database. En wat heeft de strip_tags voor nut als je een htmlspecialchars hebt gedaan?

[bindsa]

HuHu schreef op donderdag 24 december 2009 @ 15:27:
[...]

Dat is ook niet helemaal fantastisch. Je hoort dat gewoon te doen op het moment dat je data wordt gebruikt in een query. Of wordt getoond op het scherm. Of wordt uitgelezen door je applicatie.

Niet altijd en overal en onvoorwaardelijk.

Als je nu POST data wilt opslaan in de database, dan ziet je met bewerkte gegevens in je database. En wat heeft de strip_tags voor nut als je een htmlspecialchars hebt gedaan?

Dat van strip tags ben ik met je eens. Over de rest valt te twisten, ik vind het makkelijk als ik niet meer hoef op te letten voor SQL injecties, vandaar dat stuk code. Verder doe ik ook nog checks in de scripts zelf met preg_match() en/of ereg().

[XiniX88]

Gedachtespinsel: PHP wordt opgebouwd in temp (en moet nu een hele FILE inladen)... temp staan sessies in, temp map mag niet te groot worden, sessies worden opgeruimd..

Probeer het eens lokaal en kijk of het daar ook gebeurd. Als dat zo is, lijkt het me een scripting fout, maar kan die zo 1 2 3 niet zien. Als het niet zo is moet je het zoeken bij je hosting (maar die conclusie leek mij vrij logisch).

Succes!

[ Voor 20% gewijzigd door XiniX88 op 24-12-2009 17:20 ]

[HuHu]

L0calh0st schreef op donderdag 24 december 2009 @ 16:47:
[...]


Dat van strip tags ben ik met je eens. Over de rest valt te twisten, ik vind het makkelijk als ik niet meer hoef op te letten voor SQL injecties, vandaar dat stuk code. Verder doe ik ook nog checks in de scripts zelf met preg_match() en/of ereg().

En wat nu als je POST gegevens in je database wil opslaan en die vervolgens (later een keer) wil tonen in een PDF document? Dan zit je met bijvoorbeeld met een " in je tekst.

En wat als je GET of POST gegevens wil tonen op het scherm in HTML? Voor elke ' komt een \ te staan, wat er stom uit ziet. Je GET-gegevens zijn niet door htmlspecialchars() gehaald, maar je POST wel.

De behandeling die je data via een POST geeft pas je niet toe op exact dezelfde data aanwezig in $_REQUEST.

Al met al is het maar een warboel van dingen.

[Cartman!]

Met HuHu. Kom op, doe iets met die adviezen. Wat je nu doet is enorme bad practice, punt.

Voor een paar tientjes per jaar heb je al vrij betrouwbare hosting, waarom bij die gratis rotzooi blijven hangen Verder kun je eens kijken naar een eigen session handler, dan heb je niks meer te maken met hostspecifieke instellingen of ander geleuter met $_SESSION in php.

[kokx]

Wat jij doet is nogal een behoorlijke bad practise idd. Buiten de redenen die HuHu aangeeft.

Daarnaast mag je ook bedenken, er zijn een hoop scripters die magic_quotes juist UIT willen hebben, omdat ze dat zelf wel oplossen, er worden vaak zelfs oplossingen voor geschreven die de quotes juist verwijderen. Terwijl jij ze er lekker bij gaat zetten.

Dat mensen dat niet willen, is niet voor niets, buiten de redenen die HuHu aangeeft, leer je er ook nog eens niets van. Consequent je input op de juiste manier escapen is toch wel erg belangrijk. Niet alle input wil je htmentities van maken, niet alle input gaat in een database.

En dan nog iets veel belangrijkers: niet alle user input gaat via $_POST, $_GET, $_REQUEST en $_COOKIE. Een groot deel van de user-input gaat ook via $_SERVER!!!!! Door deze oplossing mis je die juist totaal, omdat je niet denkt aan escapen waar het wel nodig is.

[HuHu]

magic_quotes is deprecated en wordt vanaf PHP 6 zelf volledig verwijderd. Daar moet je sowieso al niet op vertrouwen.

[bindsa]

Allereerst hartstikke bedankt voor jullie reacties.

Betaalde hosting is op dit moment nog niet mogelijk om de applicatie nog niet af is en de hosting geregeld wordt als de applicatie af is.

Over mijn beveilingsmethode is inderdaad discussie mogelijk. Ik voor mezelf vind het makkelijk om centraal te escapen, zodat ik hier in mijn scripts niet meer om hoef te denken. Dat de escaping niet perfect weet ik, daarom check ik in mijn scripts vaak nog met ereg() en preg_match() (Dat doe ik in de scripts omdat de format van de ingevulde data verschilt).

Graag wil ik nog wel even vermelden dat dit mijn eerste PHP applicatie is en dat deze dus lange van perfect is, ook ben ik niet de enige die aan dit project meewerkt, er zit een hele projectgroep achter.

[Stewie!]

Kan je controleren of de sessie file gelocked wordt (en blijft na de download)? Dat kan ook wel eens problemen geven.

[bindsa]

Stewie! schreef op maandag 28 december 2009 @ 15:11:
Kan je controleren of de sessie file gelocked wordt (en blijft na de download)? Dat kan ook wel eens problemen geven.

Dat probleem is inmiddels opgelost door de duur van een sessie met php_ini_set() te veranderen. Blijkbaar lag het daaraan.

[Cartman!]

L0calh0st schreef op maandag 28 december 2009 @ 15:06:
Betaalde hosting is op dit moment nog niet mogelijk om de applicatie nog niet af is en de hosting geregeld wordt als de applicatie af is.

Betaalde hosting heeft niks te maken met af of niet af Het heeft te maken met een paar tientjes per jaar waardoor je wellicht van een hele hoop vage problemen afbent omdat je bij een pauperhost zit.

Graag wil ik nog wel even vermelden dat dit mijn eerste PHP applicatie is en dat deze dus lange van perfect is, ook ben ik niet de enige die aan dit project meewerkt, er zit een hele projectgroep achter.

Dan zou ik je hele projectgroep aanspreken op de bad practice waar je hier op gewezen bent, dat zeggen we niet om je te pesten maar zodat je er van kunt leren.

offtopic:
Let je trouwens op dat de ereg_* functies depricated zijn in PHP5.3 en verdwijnen in PHP6?