Specific PHP session variables disappearingin Firefox and Chrome - Codeigniter

[Nick333]

I am setting two session variables from post values in a controller. They persist after loading the next view but then are mysteriously set to NULL after another view is loaded. All other session variables are untouched regardless of whether I set them before the controller runs or in the same controller.

<?php $attributes = array('class' => 'form-group');
echo form_open('dates_validation', $attributes);?>
    <label for="arrival_date">Arrival date:</label>
    <input class="form-control" type="text" id="datepicker" name="arrival_date"
       style="width:120px" onchange="function1()"><br />
    <label for="departure_date">Departure date:</label>
    <input class="form-control" type="text" id="datepicker2" name="departure_date"
       style="width:120px" onchange="function1()"><br />

Controller:

$this->session->set_userdata('arrival_date', $_POST['arrival_date']);
$this->session->set_userdata('departure_date', $_POST['departure_date']);

I've tried using native sessions.

This happens in Chrome and Firefox but not Edge.

Thanks in advance.

 

[Other Pineapple Smurf]

I had the same problem a couple of years back and ended up that I was exceeding COOKIE size. Also remember this was browser dependant. Don't store session data in cookie, rather to disk / db / memcached if you can.

 

[Nick333]

I had the same problem a couple of years back and ended up that I was exceeding COOKIE size. Also remember this was browser dependant. Don't store session data in cookie, rather to disk / db / memcached if you can.

Well, I have it set to 'files' which I assume is the codeigniter equivalent of disk. If I set it to database, memcached or redis(whatever that is) it just breaks the site. I've actually added a couple of nonsense session variables just to see if they behave the same - they don't - so I don't think it has anything to do with cookies or cookie size. I assume if it did the new variables would also break because the cookie would be at it's size limit already.

 

[IndigoIdentity]

You could test that sessions are working correctly on the server by creating two separate files, test1 and test2.php.

In test1 do:

<?php
session_start();
$_SESSION['test'] = 'testing sessions';

In test2 do:

<?php
session_start();
echo $_SESSION['test'];

So then, visit test1.php in your browser to set the session, then visit test2.php in your browser to ensure that it will print the session value. It this works then your sever is handling the sessions correctly.

If that is the case, it seems that you're overriding the session value somewhere or maybe the cookie (stores session hash) validity period is set very low and expiring almost instantly?

 

[Other Pineapple Smurf]

Issues that have bitten me as well:
* Session start not being called before writing session. The session value will still be avaialble but not persist.
* The headers are flushed before session start is called - the number one pain of PHP sessions.
* Session end being called before writing session. Same issue as above.
* Code that is filtering your session data (happened once before).
* Using a session value that is overwritten by other code - remember that saving a null to a session deletes it so you could have code writing a NULL to the session value.

If you are writing to files, monitor that file and inspect it.

Sessions are the biggest pain in PHP.

 

[Nick333]

You could test that sessions are working correctly on the server by creating two separate files, test1 and test2.php.

In test1 do:

<?php
session_start();
$_SESSION['test'] = 'testing sessions';

In test2 do:

<?php
session_start();
echo $_SESSION['test'];

So then, visit test1.php in your browser to set the session, then visit test2.php in your browser to ensure that it will print the session value. It this works then your sever is handling the sessions correctly.

If that is the case, it seems that you're overriding the session value somewhere or maybe the cookie (stores session hash) validity period is set very low and expiring almost instantly?

I'm doing a var dump on each page and like I said I've tried setting other nonsense variables at the same time as the other two and they persist while the other two are set to null. My session expiration is set to 7200 seconds.

 

[Nick333]

Issues that have bitten me as well:
* Session start not being called before writing session. The session value will still be avaialble but not persist.
* The headers are flushed before session start is called - the number one pain of PHP sessions.
* Session end being called before writing session. Same issue as above.
* Code that is filtering your session data (happened once before).
* Using a session value that is overwritten by other code - remember that saving a null to a session deletes it so you could have code writing a NULL to the session value.

If you are writing to files, monitor that file and inspect it.

Sessions are the biggest pain in PHP.

I'm doing a var dump on the next page which shows the two variables set to the desired values but when I check the session file at the same time the variables are already set to null.

 

[[)roi(]]

Have you checked that these values remain consistent?:

echo session_id();
echo ini_get('session.cookie_domain');

 

[Nick333]

Have you checked that these values remain consistent?:

echo session_id();
echo ini_get('session.cookie_domain');

The session id stays the same. The second prints nothing.

 

[[)roi(]]

/Edit

The session id stays the same. The second prints nothing.

Ok good;
Thinking about this again; you are able to set and retrieve the session values in the current view i.e. the form, and then are successfully able to retrieve these in the next view: assume that's the one after form is posted. The third form I assume is next progression in your workflow.

If those assumptions are correct, then the only reason I can think of for the failure is that:

1. The timeout is exceeded (unlikely re you set this to 7200)
2. Either of the session_id, session_name, cookie_domain is inconsistent
3. Multiple subdomains are used: cookie_domain should fix that.
4. An intermediate step overwrites the values
5. The hosting company / or your server settings could be causing this, e.g. they might have some .htaccess rules that could impact session state.

Anyway you could also try fixing the session_name and cookie_domain to see if that changes anything.

Set session name & cookie domain

$current_session_name = session_name("new_session_name");
session_set_cookie_params(0, '/', '.some_domain.com');
session_start();

Note: setting the session name is not going to work if you have set in your php.ini "session.auto_start" to "true" or "1", default btw is "0"

Anyway that's all I can think off for now.

 

[Nick333]

/Edit

Ok good;
Thinking about this again; you are able to set and retrieve the session values in the current view i.e. the form, and then are successfully able to retrieve these in the next view: assume that's the one after form is posted. The third form I assume is next progression in your workflow.

If those assumptions are correct, then the only reason I can think of for the failure is that:

1. The timeout is exceeded (unlikely re you set this to 7200)
2. Either of the session_id, session_name, cookie_domain is inconsistent
3. Multiple subdomains are used: cookie_domain should fix that.
4. An intermediate step overwrites the values
5. The hosting company / or your server settings could be causing this, e.g. they might have some .htaccess rules that could impact session state.

Anyway you could also try fixing the session_name and cookie_domain to see if that changes anything.

Set session name & cookie domain

$current_session_name = session_name("new_session_name");
session_set_cookie_params(0, '/', '.some_domain.com');
session_start();

Note: setting the session name is not going to work if you have set in your php.ini "session.auto_start" to "true" or "1", default btw is "0"

Anyway that's all I can think off for now.

I've tried what I can there, but I can't access the php.ini on shared hosting. Do you think this would address the problem for a browser specific issue though? The fact that it works fine on IE and Edge makes me think PHP is set up properly.

*Like you say the timeout thing is unlikely. Also like I said other variables persist, it's just these two.
*name, id, and domain are consistent.
*an intermediate step may well be over writing - god knows I've gone through my code and can't find anything that is.
*I've tried two different server from different hosts. In fact I could have sworn this was working on Chrome before moving so who knows. I'll double check that. Nope - would have been interesting though.

Do you think this could have anything to do with the variables being set by Datepicker? I don't see how myself because the variables are stored for at least a time and the scripts are only run on the first page.

This is doing my head.

 

[[)roi(]]

I've tried what I can there, but I can't access the php.ini on shared hosting. Do you think this would address the problem for a browser specific issue though? The fact that it works fine on IE and Edge makes me think PHP is set up properly.

*Like you say the timeout thing is unlikely. Also like I said other variables persist, it's just these two.
*name, id, and domain are consistent.
*an intermediate step may well be over writing - god knows I've gone through my code and can't find anything that is.
*I've tried two different server from different hosts. In fact I could have sworn this was working on Chrome before moving so who knows. I'll double check that.

Do you think this could have anything to do with the variables being set by Datepicker? I don't see how myself because the variables are stored for at least a time and the scripts are only run on the first page.

This is doing my head.

Nope re Datepicker. As you say the values persist to the second page, so they are being set?.
As for a configuration issue, either .htaccess or php.ini -- it's also unlikely as that would have affected everything or a particular sub domain and not just a later page in a workflow.

Have you tried just a standard cookie to see if that persists?

session_set_cookie_params(0, '/', '.your_domain.com');
session_start();  
// ...
// ...
// ...

setcookie("TestCookie", $value, time()+3600);  /* expire in 1 hour */

Then in the receiving page, something like this

session_set_cookie_params(0, '/', '.your_domain.com');
session_start();  

// then after the page reloads, just print them out
if (isset($_COOKIE['cookie'])) {
    foreach ($_COOKIE['cookie'] as $name => $value) {
        $name = htmlspecialchars($name);
        $value = htmlspecialchars($value);
        echo "$name : $value <br />\n";
    }
}

 

[Nick333]

Nope re Datepicker. As you say the values persist to the second page, so they are being set?.
As for a configuration issue, either .htaccess or php.ini -- it's also unlikely as that would have affected everything or a particular sub domain and not just a later page in a workflow.

Have you tried just a standard cookie to see if that persists?

session_set_cookie_params(0, '/', '.your_domain.com');
session_start();  
// ...
// ...
// ...

setcookie("TestCookie", $value, time()+3600);  /* expire in 1 hour */

Then in the receiving page, something like this

session_set_cookie_params(0, '/', '.your_domain.com');
session_start();  

// then after the page reloads, just print them out
if (isset($_COOKIE['cookie'])) {
    foreach ($_COOKIE['cookie'] as $name => $value) {
        $name = htmlspecialchars($name);
        $value = htmlspecialchars($value);
        echo "$name : $value <br />\n";
    }
}

TBH I don't no were to put the code in the codeigniter framework. When I do get it to run it breaks all my session variables. I'm about ready to toss it all and rewrite the whole thing in native PHP.

 

[EMAM]

I'm about ready to toss it all and rewrite the whole thing in native PHP.

Noooooo.......I CAN'T go through this again

 

[[)roi(]]

TBH I don't no were to put the code in the codeigniter framework. When I do get it to run it breaks all my session variables. I'm about ready to toss it all and rewrite the whole thing in native PHP.

My bad, didn't pick up on codeigniter in title. That changes things, because the framework design i.e. Where and when you can set and read values is important, and the breakdown could be related simply to that.

Sorry but I'm not familiar with codeigniter -- I've tended to avoid most frameworks because they work against my more functional approach. BUT that shouldn't be a reason for you to bailout.

Plus knowing it's codeigniter is probably going to make this a lot easier to self diagnose.. I.e. I'd start checking for reasons for session persistence failure with codeigniter.

 

[[)roi(]]

Quick check reveals that session issues can be problematic with codeigniter, but you don't have to throw away the framework to use native session handling. There is even a Wiki on this with examples: https://github.com/bcit-ci/CodeIgniter/wiki/Native-session

Ps. The related stackoverflow post that led to this is here: http://stackoverflow.com/questions/...data-not-available-in-other-pages-after-login

Also have a look at this, seems similar: http://billpatrianakos.me/blog/2013/03/22/codeigniter-session-problems/

 

[Nick333]

Quick check reveals that session issues can be problematic with codeigniter, but you don't have to throw away the framework to use native session handling. There is even a Wiki on this with examples: https://github.com/bcit-ci/CodeIgniter/wiki/Native-session

Ps. The related stackoverflow post that led to this is here: http://stackoverflow.com/questions/...data-not-available-in-other-pages-after-login

Also have a look at this, seems similar: http://billpatrianakos.me/blog/2013/03/22/codeigniter-session-problems/

Thanks for your help. I've tried native sessions. In fact I switched to native sessions earlier in the project to solve a similar problem. This problem cropped up while using native sessions.

For anyone who is interested I wouldn't recommend using codeigniters session library there seems to be no upside except for some configuration it allows you to do. You can call session_start() in index.php and be done with it.

I suspect my problem has something to do with some or compatibility issue with my hosts php set up and codeigniter.

 

[[)roi(]]

Thanks for your help. I've tried native sessions. In fact I switched to native sessions earlier in the project to solve a similar problem. This problem cropped up while using native sessions.

For anyone who is interested I wouldn't recommend using codeigniters session library there seems to be no upside except for some configuration it allows you to do. You can call session_start() in index.php and be done with it.

I suspect my problem has something to do with some or compatibility issue with my hosts php set up and codeigniter.

Have you considered using the database for the session management, as suggested here: http://stackoverflow.com/a/9285938/6763793 and here: http://billpatrianakos.me/blog/2013/03/22/codeigniter-session-problems/

Use the database
When I first started developing Write.app I had a problem where sessions just weren’t being set at all. I tried a ton of different solutions (not including those above but including those below) and none worked. In the end I found that if I used the database everything just worked. In the end I needed this feature for technical reasons so it wasn’t for nothing.

 

[Nick333]

Have you considered using the database for the session management, as suggested here: http://stackoverflow.com/a/9285938/6763793 and here: http://billpatrianakos.me/blog/2013/03/22/codeigniter-session-problems/

I have tried but it simply doesn't work and breaks the site completely because I have a session variable set that points to a db table that pretty much everything relies on. I'll give it another go though. Might be a configuration problem.