[PHP] $_SESSION['bla'] blijft leeg

[Rickbv]

Met het maken van een webshop loop ik tegen een probleem aan. Hier lokaal heb ik alles werkend en wel, maar nu ik het upgeload heb naar NXS werkt het bestelproces opeens niet meer.

Bij het bestelproces worden namelijk de variabelen uit de forms stap voor stap in de $_SESSION var geschreven. Een voorbeeldje:

PHP:

      if ($_GET['ref']=="betvergeg") {
         if (is_numeric(trim($_POST['verzendmethode']))) {
            $_SESSION['betvergeg']['verzendmethode'] = $_POST['verzendmethode'];
         }
         else {
            unset($_SESSION['betvergeg']['verzendmethode']);
         }
         if (is_numeric(trim($_POST['betaalmethode']))) {
            $_SESSION['betvergeg']['betaalmethode'] = $_POST['betaalmethode'];
         }
         else {
            unset($_SESSION['betvergeg']['betaalmethode']);
         }
      }

Bij het bestellen worden dus bijvoorbeeld dingen als verzendmethode vastgelegd in $_SESSION['onderdeel']['verzendmethode']. Het probleem is echter dat deze niet worden op geslagen op de een of andere manier. Ik weet zeker dat bovenstaande code wordt uitgevoerd (getest met een simpele 'echo'). Het vreemde is dat de waardes in de $_SESSION['winkelmand']-variabele wel 'onthouden' worden, deze bestaat uit:

PHP:

$_SESSION['winkelmand'][] = array($type, $aantal, $art_id)

Dit probleem heb ik alleen op de server van NXS, hier thuis werkt het prima. Ik heb eens naar de phpinfo() van beide gekeken, maar zie weinig verschillen eigenlijk. Hier de phpinfo van NXS:

code:

Session Support  enabled  
Registered save handlers  files user  

Directive Local Value Master Value 
session.auto_start Off Off 
session.bug_compat_42 On On 
session.bug_compat_warn On On 
session.cache_expire 180 180 
session.cache_limiter nocache nocache 
session.cookie_domain no value no value 
session.cookie_lifetime 0 0 
session.cookie_path / / 
session.cookie_secure Off Off 
session.entropy_file no value no value 
session.entropy_length 0 0 
session.gc_divisor 100 100 
session.gc_maxlifetime 1440 1440 
session.gc_probability 1 1 
session.name PHPSESSID PHPSESSID 
session.referer_check no value no value 
session.save_handler files files 
session.save_path /tmp /tmp 
session.serialize_handler php php 
session.use_cookies On On 
session.use_only_cookies Off Off 
session.use_trans_sid On On

Ik hoop dat jullie me enige aanwijzingen kunnen geven in de goede richting, want ik weet echt niet waar het probleem zou kunnen zitten. Als er namelijk iets fout is aan de manier van $_SESSION vullen, dan is dat over het hele script (1000 regels) fout, dat kan ik niet zomaar even aanpassen om te testen of dat de oorzaak was...

[crisp]

welke versie PHP draait er op die NXS server?

[Rickbv]

Bij NXS draait momenteel PHP Version 4.3.4, hier lokaal PHP Version 4.3.3.

[mr_obb]

Hoe roep je later de waarden in de array weer op? Als je dat doet met bijv:

PHP:

echo ($_SESSION['betvergeg'][1]);

dan kan het fout gaan met de indices. Bij het gebruik van unset() wordt de index namelijk niet vrijgegeven. Als je dan een nieuwe waarde toekent aan bijv. verzendmethode, dan komt deze te staan op plaats 3, omdat 1 en 2 al gebruikt waren, ook al heb je met unset($_SESSION['betvergeg']['verzendmethode']) de waarde gewist.

De beste manier is dus:

PHP:

echo ($_SESSION['betvergeg']['verzendmethode']);

Array indices resetten kan met array_values(). Voor de methode zie: hier.

[ Voor 13% gewijzigd door mr_obb op 29-02-2004 14:03 ]

[Spider.007]

Kun je enige nuttige informatie halen uit

PHP:

print_r($_SESSION)

[ACM]

doe je wel ergens session_start ?

[Rickbv]

@mr_obb & Spider.007: print_r had ik al geprobeerd, daar kwam wel een volledige winkelmand te staan, maar geen enkele waarde van betvergeg of klantgeg.

@ACM: bovenaan m'n script staat keurig session_start() ja, anders zou hij het lokaal ook niet moeten doen toch?

Ik kan niet even snel de complete code hier neer gooien (werkt ook met templates enzo), dus zal nog even een paar (relevante) stukken posten...

Kortgezegd bestaat het bestelscript uit de volgende onderdelen:
0) globale pagina settings
1) kijken uit welk formulier gepost wordt ($ref)
2) daaruit de variabelen in $_SESSION['ref'] opslaan
3) kijken welke stappen genomen zijn in het proces (weergeven)
4) aan de hand daarvan volgende pagina tonen

Bijbehorende code:

0:

PHP:

session_start();
ini_set("session.cookie_domain","blaat.nl");
   include('config.php');
   include("class.FastTemplate.php3");
   include('template_declarations.php');
   //na $_SESSION-codes:
   $tpl = new FastTemplate("./templates");
   $tpl->define($bestanden);
   include('general_definitions.php');

1 & 2:

PHP:

   if($_GET['p'] == "bestel") {

      if ($_GET['ref']=="betvergeg") {
         if (is_numeric(trim($_POST['verzendmethode']))) {
            $_SESSION['betvergeg']['verzendmethode'] = $_POST['verzendmethode'];
         }
         else {
            unset($_SESSION['betvergeg']['verzendmethode']);
         }
         if (is_numeric(trim($_POST['betaalmethode']))) {
            $_SESSION['betvergeg']['betaalmethode'] = $_POST['betaalmethode'];
         }
         else {
            unset($_SESSION['betvergeg']['betaalmethode']);
         }
      }
      else if ($_GET['ref'] == "klantgeg") {
         // enzovoorts
      } 
   }

3:

PHP:

// Betaal en verzendmethode
      $betvergeg = BestelStapGenomen('betvergeg',BestelStappenChecken());
      if ($betvergeg == true) {
         $img = 'done';
         $bestel_procent = $bestel_procent + 20;
      }
      else {
         $img = 'undone';
      }
      // Laden template met vars

4:

PHP:

   if ($_GET['p'] == "bestel" && ($betvergeg == false || $bestel_wijzig == "betvergeg")) {
      $tpl->assign(array(NAVBAR_LINK_url    => "bestel.php?p=bestel",
                         NAVBAR_LINK_target => "_self",
                         NAVBAR_LINK_naam   => "Verzend en betaalmethode kiezen"));
      // andere form-template zooi
   }

Nogmaals, hier thuis werkt het perfect, maar op een andere server niet. Dan kan het dus of aan bepaalde server-settings liggen, of ik gebruik ergens een ranzige code die hier thuis wel toegestaan/werkend is, maar daar bij NXS niet. En het grootste probleem is dus dat ik niet weet waar ik moet kijken, het kan op vrij veel plaatsen fout gaan.

[ Voor 75% gewijzigd door Rickbv op 29-02-2004 14:32 ]

[AuC]

Ik ben een n00b op het gebied van sessions in PHP, maar mag je sessions wel zo registreren?

PHP:

$_SESSION['betvergeg']['verzendmethode'] = $_POST['verzendmethode'];

Ik heb het altijd zo geleerd:

PHP:

$bla = $_POST['blaat'];
session_register( $bla );

Is ook maar een wilde gok hoor.

edit:
Aaah, sorry. Niet goed gelezen geloof ik

[ Voor 16% gewijzigd door AuC op 29-02-2004 15:35 ]

[Verwijderd]

AuC schreef op 29 februari 2004 @ 15:31:

Ik heb het altijd zo geleerd:

PHP:

$bla = $_POST['blaat'];
session_register( $bla );

Is ook maar een wilde gok hoor.

Hééél vroegâh was dat zo ja. Maar sinds PHP 4.1.0 en zéker sinds 4.2.0 wordt aangeraden om gebruik te maken van de superglobals, dus ook $_SESSION. Dat is dus al bijna twee jaar geleden!

[Rickbv]

Ik doe nog maar eens een kickje... Heb het script al 2 maal helemaal doorlopen, maar heb tot dusver nog niets kunnen vinden. Daarnaast heb ik het geheel nog even op een andere server gezet, ook daar werkte het bestellen niet (de $_SESSION['betvergeg'] lijkt niet onthouden te worden, $_SESSION['winkelmand'] wel). Iemand die mij een stap in de goede richting kan geven?

[DataGhost]

register_globals
check je php.ini van jouzelf en van je server.. 99% zeker dat register_globals in beide anders staat

[Rickbv]

dataghost schreef op 02 maart 2004 @ 21:26:
register_globals
check je php.ini van jouzelf en van je server.. 99% zeker dat register_globals in beide anders staat

Je hebt nog gelijk ook

Hier thuis staat register_globals op Off, op de server staat het On. Nu dacht ik altijd dat Off de veilige manier was, en dat daarvoor $_bladiebla gebruikt moest worden? Heeft het dan toch meer invloed dan ik dacht?

[DataGhost]

Rickbv schreef op 02 maart 2004 @ 21:34:
[...]

Je hebt nog gelijk ook

Hier thuis staat register_globals op Off, op de server staat het On. Nu dacht ik altijd dat Off de veilige manier was, en dat daarvoor $_bladiebla gebruikt moest worden? Heeft het dan toch meer invloed dan ik dacht?

jep het maakt heel veel uit... wat het precies met sessies uit maakt weet ik ff niet uit me hoofd, zal ik zo ff opzoeken op php.net
iig met register_globals on zet ie automatisch alle post get cookie whatev variabelen in normale variabelen, waardoor je met een get argument zo een deel van je script kan lamleggen en zelfs dingen kan achterhalen (zoals $sql ofzo wijzigen hoe die wordt doorgegeven ..mjah nvm maar het kan dus)
sinds php v4.2.0 staat het standaard op off, voor veiligheid

edit: php 4.2.0 was het

rest van edit:

When on, register_globals will inject (poison) your scripts will all sorts of variables, like request variables from HTML forms. This coupled with the fact that PHP doesn't require variable initialization means writing insecure code is that much easier. It was a difficult decision, but the PHP community decided to disable this directive by default. When on, people use variables yet really don't know for sure where they come from and can only assume. Internal variables that are defined in the script itself get mixed up with request data sent by users and disabling register_globals changes this. Let's demonstrate with an example misuse of register_globals:

code:

<?php
// define $authorized = true only if user is authenticated
if (authenticated_user()) {
   $authorized = true;
}

// Because we didn't first initialize $authorized as false, this might be
// defined through register_globals, like from GET auth.php?authorized=1
// So, anyone can be seen as authenticated!
if ($authorized) {
   include "/highly/sensitive/data.php";
}
?>

zie alhier
http://www.php.net/register_globals

[ Voor 42% gewijzigd door DataGhost op 02-03-2004 21:43 ]

[Rickbv]

dataghost schreef op 02 maart 2004 @ 21:38:
[...]

Heb hier thuis ff register_globals op On gezet en inderdaad, het werkt niet meer. dataghost

Dat deze setting op On veiligheidsrisico's met zich mee bracht wist ik best, daarom had ik het hier thuis al Off gezet. Maar dan verwacht je toch dat iets als NXS dat ook doet. Had er ook eigenlijk helemaal geen rekening meer mee gehouden... Ik zal in ieder geval wel eens even kijken of het mogelijk is die setting op Off te krijgen, anders zou ik iets aan het script moeten veranderen. Maar wat dat veranderen in zou moeten houden, daar ben ik nog niet uit

[ Voor 8% gewijzigd door Rickbv op 02-03-2004 21:49 ]

[Verwijderd]

Als je de volgende regel in een .htaccess file in de webroot zet, heb je kans dat het werkt:

code:

php_flag register_globals 0

[ Voor 9% gewijzigd door Verwijderd op 02-03-2004 21:51 ]

[Rickbv]

Verwijderd schreef op 02 maart 2004 @ 21:51:
Als je de volgende regel in een .htaccess file in de webroot zet, heb je kans dat het werkt:

code:

php_flag register_globals 0

Had het inderdaad gevonden op de PHP site, toch bedankt. Inmiddels werkt het script, register_globals staat nu Local Off, Master On. Dat bleek dan toch de oorzaak te zijn. Ontzettend bedankt voor de hulp in ieder geval, ik zelf had hier noooit aan gedacht en had waarschijnlijk al een ander script gebouwd

[crisp]

wat er natuurlijk kan gebeuren met globals ON is het volgende:

PHP:

session_start();

$_SESSION['bla'] = 'iets';

$bla = 'iets anders';

echo $_SESSION['bla'];

drie maal raden wat de output is...

[DataGhost]

Verwijderd schreef op 02 maart 2004 @ 21:51:
Als je de volgende regel in een .htaccess file in de webroot zet, heb je kans dat het werkt:

code:

php_flag register_globals 0

dat staat ook in de reacties bij dat artikel, incl instructies om je cookie path erges anders heen te leiden...

dit heb ik in een htaccess file

php_flag register_globals off
php_value session.save_path /pad/naar/mn/home/dir/httpdocs/sess/users
php_value session.gc_maxlifetime 999
php_value include_path .:/pad/naar/mn/home/dir/httpdocs/sess

wel ff chmod 777 he

[DataGhost]

hier stond iets doms... k was vergeten mn local register_globals uit te zetten lol...

[ Voor 150% gewijzigd door DataGhost op 02-03-2004 22:33 ]

[Rickbv]

crisp schreef op 02 maart 2004 @ 22:11:
wat er natuurlijk kan gebeuren met globals ON is het volgende:

PHP:

session_start();

$_SESSION['bla'] = 'iets';

$bla = 'iets anders';

echo $_SESSION['bla'];

drie maal raden wat de output is...

Stom stom stom dat ik daar niet aan gedacht heb Kijk namelijk eens naar dit bericht, en dan met name naar 'code 3'. Een maal raden waarom $_SESSION['betvergeg'] zich niet zoals verwacht gedroeg...

[ Voor 20% gewijzigd door Rickbv op 02-03-2004 22:28 ]