Can't fetch flashdata if database sessions are being used #700

Closed
AeroCross opened this Issue Nov 23, 2011 · 4 comments

5 participants

@AeroCross

In any given controller, setting database sessions to TRUE:

<?php
    $this->load->library('session');

    $this->session->sess_destroy(); // all the session data up to here should be destroyed, but the remaining data should persist
    $this->session->set_userdata('message', 'This is the userdata message.');
    $this->session->set_flashdata('message', 'This is the flashdata message.');

    var_dump($this->session->flashdata('message')); // bool(false)
    var_dump($this->session->userdata('message')); // string(29) "This is the userdata message."
?>

... but if I set database sessions to FALSE:

<?php
    $this->load->library('session');

    $this->session->sess_destroy(); // all the session data up to here should be destroyed, but the remaining data should persist
    $this->session->set_userdata('message', 'This is the userdata message.');
    $this->session->set_flashdata('message', 'This is the flashdata message.');

    var_dump($this->session->flashdata('message')); // string(30) "This is the flashdata message."
    var_dump($this->session->userdata('message')); // string(29) "This is the userdata message."
?>

My database scheme is the exact same scheme as the one in the user guide.

I don't know what kind of configuration can corrupt the generation of the flashdata - the only think I could think about is the cookie limit of 4K, since I'm encrypting the session and such (but since there are database sessions, I thought that wasn't the problem). The size of the serialized array shouldn't be a problem either (since the example is really small and there is no other data around).

It's worth noting that the problem appears ONLY if I destroy the session before calling the set_userdata.

I don't know what other information to give out. Is this the proper behavior or it's a bug?

@johnnicely

Sorry about the little 🆕 images here... Not sure how to escape them. Just assume each of those to be 'new' wrapped in colons.

The short version of why this is happening is that set_flashdata('key', 'value') modifies 'key' to have a flashdata tag and then calls set_userdata() with the new key and old value. This key is in the format 'flash🆕key' (after the next page load, $CI->session->_flashdata_sweep() deletes any variables with ':old:' and $CI->session->_flashdata_mark() changes any userdata variables with '🆕' to use ':old:': 'flash:old:key').

For some reason, when the database is used for storage, $CI->session->userdata (the array in CI_Session that holds the userdata information, including flashdata) only has 'flash🆕key'. When the database is not used, $CI->session->userdata has both keys ('flash🆕key' and 'flash:old:key').

Because $CI->session->flashdata('key') specifically looks for 'flash:old:key' in $CI->session->userdata, not 'flash🆕key', and because $CI->session->_flashdata_mark() (reminder: changes '🆕' to ':old:' on next page load) is only called in $CI->session->__construct(), there is no value to return in $CI->session->userdata.

That's why the issue is happening... Trying to figure out the where right now. I'll update at a later date if I find it...

@maximerassi

I've gotten flashdata working with the database sessions by setting $config['sess_match_useragent'] = FALSE;
This issue could be related to this setting.

@cryode

I've ONLY used database sessions in my experience with CI, and I've never had an issue with flashdata, except when I had an issue with sessions sticking in the first place (which is resolved with various tweaks depending on your server / settings, such as sess_match_useragent as mentioned.

Unless @johnnicely wants to update this if he's still experiencing issues (since this is a year old), might as well close and move on.

@narfbg

Honestly, this behavior should be expected, due to the nature of cookies (which is our storage when you don't use the database) - you can't write and read the same data from them in the same request, simply because what you've written is yet to be re-sent by the browser.

@narfbg narfbg closed this May 17, 2013
@baypup baypup pushed a commit to baypup/CodeIgniter that referenced this issue Aug 20, 2015
@benedmunds benedmunds Fixed type with loading
Resolves issue #700.
b26960f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment