Jump to content

Recommended Posts

Hi

 

This is not really a question but an answer to something that had been driving me nuts. I hadn't found this answer anywhere but I believe it's something that must occur with similar setups.

 

The setup is as follows:

Locally (ie development using a local box and localhost)

Mac OS X (but this is not really relevant could be anyother OS)

MySQL database

PHP 5.2.4 activated

WebSharing turned on (which in Mac OS X turns on Apache and makes the localhost active for the Sites folder)

VirtualHosting applied (in this case setup using VirtualHostX for multiple Vhosts)

VirtualHost setup using VirtualHostX to refer to the specific folder in "Sites" so that I can use eg test.my-domain.com in the browser to go to my local site

Files uploaded to a specific folder in the "Sites" folder

 

WWW host (ie the published site)

MySQL database

PHP 5.2.4 activated

Hosted in the US

Files uploaded by FTP identical to those in Sites folder above

access my site as normal www.my-domain.com

 

Site comprises

Main Page - PHP Scripts to select records from a database to dynamically configure site objects and text.

Main Page - Uses Javascript to provide Application-like behaviours for users.

Main Page has in-line Frames to display other pages on the site.

Feedback page - with reCaptcha (POST method to PHP script)

Other pages not relevant to this explanation.

 

Mechanism in Question

Feedback form submits data to php script to

a) process reCAPTCHA and return to Feedbackpage if necessary or

b) insert to MySQL database and issue email confirmation

 

Both a and b functioned but I was not getting the form values to appear in the form fields even though I was using sessions.

 

This is where I learnt something important: nobody anywhere seems to be able to clearly explain what happens to the variables in the PHP session, the relevance of the cookie, and finally the impact of the php.ini file and the type of host used.

 

The result is that unless all three of these elements are configured well your sessions may not work.

 

So here goes...

The first bit to understand is that websites are stateless. I know you know this but just in case. This means that nothing is retained or "remembered" without you making a place for it to be retained and then bringing it back to life. For example hitting the "back" button does not mean that you have retained form data even though all the fields in the form you just completed are filled in. It's your browser doing this NOT the website. That's just an example but you need to know what your looking at and what the difference is!

 

The second bit is that by adding sessions (and this http://www.linuxdevcenter.com/pub/a/php/2001/04/26/sessions.html is a good example of how to do that) DOES NOT mean that everything will work straight away.

 

Sessions in the default rely on PHP being able to automatically place a cookie with session ID on the client (web user's) PC, that it can refer to on another page.

 

This is the crux of the matter. This mechanism was working fine - I saw the cookie and it had the session ID, but operationally variable values were apparently being lost. Actually they weren't and here's why.

 

When you navigate or post a form to another page, the PHP engine needs to be able to identify that the cookie it placed came from a prior page is relevant for the current page, and even the current script in the case I used. This is not a bug, I've seen it explained elsewhere as a function of HTTP and it makes sense.

 

The scenario

I have www.my-domain.com (A) - that my main page.

I also have www.my-domain.com/feedback.php (B) and www.my-domain.com/Code/Processform.php ©

Just for completeness www.my-domain.com/feedback.php can be accessed directly or it can appear in the iFrame but it makes no difference here.

 

So I navigated to (B) filled in the form fields and punched an incorrect CAPtcha code and submitted.

© was called and it received all the field values in the $_POST['variablename'].

ReCaptcha did it's stuff and returned the error.

$_SESSION[variablenames] were set.

The original feedback form was called using php Header Location: with the ReCaptcha result tagged on to the URL

 

Back at the feedback form the reCaptcha result was received using $_GET (to get it from the URL)

The error message was issued.

Each of the fields had echo $_SESSION[variablename] in.... but they came out blank.

 

This drove me nuts for ages. Everywhere I looked the code was implemented correctly, and start_session() was used everywhere.

 

I eventually found the answer without changing very much at all, and it had to do with the VirtualHost mechanism, but the solution will ensure that even your live site will be configured correctly.

 

Remember I stated that you need "to be able to identify that the cookie it placed came from a prior page is relevant for the current page" - well this is about your host and in particular the part in the PHP.ini called session.cookie_domain. By default it is NULL which is OK if you are only hosting one domain, but if you are hosting multiple domains (as I do using VirtualHosting) you have a number of choices:

 

1) Reconfigure the PHP.ini manually - note this means other sites that you host don't work anymore if they use sessions because you are setting the default to another domain

 

2) Reconfigure the PHP.ini by code - note this is a massive benefit because it works both locally and on the live server. And in addition it is temporary meaning that as soon as it is no longer needed the PHP.ini file reverts to the default.

 

The Answer

All you have to do is add one line of code before your session start statement using ini_set function:

 

ini_set('session.cookie_domain','http://my-domain.com');

session_start();

 

And there you have it.

NOTE I didn't put test.my-domain.com or even www.my-domain.com I tested it without and it still works hence it's good to go for the live domain.

 

So your variable values were not lost in the session, and wherever you want to use sessions, make sure that your PHP page or script knows which domain to look for its session ID.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.