Thread

CI’s Session Library is FLAWED.

UPDATED: 11/20/2009

The following applies to version 1.7.2 of CodeIgniter.

- Trying to use DX_auth or other authentication libraries but end-users using Internet Explorer experience mysterious spontaneous log-outs or people can’t log in?

- Is your session data disappearing for IE users while your FireFox and Safari users have no problems?

- Tired of seasoned CI veterans on this forum telling you the problem is YOU not CI?

If so, you’re at the right thread.

Here is what you need to know about CI’s Sessions.

Okay, so here’s the long and short of it.  CI’s session library creates standards-compliant cookies that work reliably on all web browsers except for Internet Explorer 6,7,8 and so on.  The reason being, Internet Explorer doesn’t follow standards (link).  Kudos for CI. Shame on IE.  We all know that Microsoft’s browser is a piece of poop.  It still doesn’t change the fact that tons of people still use it because they either don’t care, don’t know, or don’t have a choice (company-owned computer).  Rather than accommodate Internet Explorer users, CI coders and CI uber-fans would prefer that you start a revolt, shun the 40% to 50% of users who use IE, lose your paying web development clients, and/or get fired.

Obviously, lots of people encounter no problems whatsoever when using CI’s session class, which makes those of us who do have problems frustrated.  Just know your not alone. A quick search on this forum revealed over 600 other posts from people having questions or issues with CI’s session class. The problem may lie with your host’s web server, it may lie with your visitor’s web browser, it may be that your code doesn’t accomodate CI somehow.  Regardless, by introducing a new layer between PHP’s perfectly adequate native session routines and the end user, CI’s session class also inevitably introduces new and annoyingly mysterious problems.

So, why invest time and effort writing code that relies on CI’s sessions when, at some point in the future, unforeseen server or browser changes have the potential of ruining your code?

I say, avoid the problems in the first place. So…

IF YOU HAVE A CHOICE:

- Starting a new project? Don’t use CI’s session class.  Just write code like you normally would outside of the CI framework.  Meaning: use PHP’s native session handling functions like session_start(), unset(), session_destroy() and the $_SESSION superglobal.

- By default, PHP stores data on the server in a world-readable location, like “/tmp”.  If you are hosted on a chrooted virtual or dedicated server, then (for the most part) there is no need to be worried. However, if you are on a traditional shared server, like at an ISP, there are PHP configuration settings you can tweak to change the location where PHP stores session data.  For example, on Apache servers you can set up a special .htaccess file.  Google that for more information.

IF YOU’RE STUCK WITH CI_SESSION:

- Did you inherit a project that relies on CI’s session class?

- Is your favorite 3rd party library dependant on CI’s session class?

If you absolutely MUST use CI’s session class, your best option is to completely replace CI’s session class with one that uses PHP’s rock-solid native session handling routines.

Current Recommended Replacements:

Dariusz Debowczyk’s Session Class

I found this solution while surfing the net for constructive help.  Dariusz’s orginal class was intended for versions prior to 1.7.2.  You place it in your application/libraries folder and it completely circumvents CI’s session class.  I tweaked some method and property names to make it work with 1.7.2.  You can find the updated code here…

http://codeigniter.com/wiki/Dariusz_Debowczyk’s_Session_Class/

Directions for how to install the class in your application are also on the above wiki page.  Please keep in mind, the Dariusz hack is that, a hack.  It needs to be improved.  Hopefully you, the reader, can improve it over time.  If you do end up improving it, please reply to this thread with your updated code.

Can’t Replace CI session class?

I feel your pain, but like I said earlier, lots of people don’t have issues with CI’s session class.  Perhaps all you need to do is…

Double check your settings.

- Examine your cookie settings in /application/config/config.php A CI vetran recomended removing underscores from the cookie name (link). This can be done by changing:

$config['sess_cookie_name']        = 'ci_session';

to

$config['sess_cookie_name']        = 'cisession';

Also remove any underscore in $config[‘cookie_prefix’] since it is prefixed to the cookie name.

Double-Check Your Server’s Time and Timezone

Make sure your server’s time is correct. All browsers set cookies based on the client’s time.  IE on the other hand, goes by server time.  If the server’s time is in the past, cookies will expire as soon as they are set thus giving the illusion that your cookie never arrived.

I would suggest using something like Native Session. This library implements the CI Session API using native PHP sessions.

This way old projects can be switched to native sessions, without changes in the code.

This approach works equally well on new projects, as the application code can remain flexible and independent of any particular session implementation.

I had the same problem with ci_session and cookies.
Until i use my local MAMP server for development i don’t have any problems with any browsers, but when i switched to the production server Safari and IE stop accepting cookies.
Instead of focusing in searching a solution for the ci_session class, i try to search on Google for general problem of IE in accepting cookies and i found the solution, at least for me.

Check this out: Session cookies rejected by Internet Explorer

I adjust the time on server and next IE and Safari start to accept cookies.

So, check the time and timezone of your server!

Hope this help someone,
bye.

Dude .. seriously ...

There’s a plethora of threads (kick-)started, most of them by you, with this pattern:
o unsubstantiated claims are made of CI Sessions not working - usually in bold, just in case it seemed implausible otherwise
o CI users with expertise and experience are discounted because they don’t agree with you
o useful suggestions to try are ignored or discounted without explanation
o requests for information on how to reproduce this problem are ignored

So far the only details I have about your problem (apart from the fact that few other people have ever seen it) are:
o mysterious spontaneous logouts
o some session data disappearing (same thing perhaps?)

Oh, and apparently if a ‘seasoned CI veteran says they can’t reproduce your problem with the non-information you’ve provided, you then feel this proves the existence of some weird conspiracy where, presumably, we all actually have badly broken sessions, but just don’t like to talk about it.

I mean .. dude .. seriously ...

And even if there’s a shred of truth to this guy’s obvious trolling, I’d say thdls55’s link makes much more sense as a drop in replacement for CI’s session class than the other suggested session class which I can’t even pronounce the name of and by their own admissions is a nasty hack anyway.

@jedd
Please complain elsewhere.  Obviously people besides me are having issues with CI’s faulty session class, otherwise they wouldn’t be responding. I’m just trying to help other CI users find viable workarounds quickly.

@ukdmbfan
Yes, Dariusz Debowczyk’s Session Class is a hack. 

@thdls55
I installed your suggested Native Session library and it works perfectly. Better than the hack. I will edit the first post to make Native Session my recommended first choice replacement.

Please, mrbinky3000, supply us with code to reproduce the problems you have encountered, and we can move this discussion forward. Along with code, we will probably need to know a lot about the server environment, your session and cookie settings, and the steps to take in the browsers to recreate the problems, as all of these affect how sessions perform.

If CI’s session library indeed does have flaws (which I have yet to experience), we’d like to work toward correcting them. Thanks.

I always use php’s $_SESSION, not because I’ve had problems with CI’s sessions, but because $_SESSION is so easy to use. For me a framework should make life easier. I create a hook to start and name the session, and I never have to worry about starting it in my controllers, libraries, models, or whatever. I still use CI sessions for flash session capabilities. It’s a beautiful thing…

That said, I’ve never had a problem with Internet Explorer and CI sessions. What I have had problems with is session_regenerate(TRUE), but that’s not CI related.

@jedd
Please complain elsewhere.

Ahh, the irony.

Obviously people besides me are having issues

You think the complete absence of people reporting the same bug, in the same nebulous detail-avoiding way as you, makes it obvious?

To whom, precisely?

I’m just trying to help other CI users find viable workarounds quickly.

Here’s a free set of clues:
o Provide information on how to reproduce the bug
o At the very least, provide information on your broken environment
o Stop starting threads that say ‘sessions are BROKEN’ (even in bold, no one is convinced)

So, to recreate.

- Grab CI, install it
- Grab dx_auth, install it. 
- Config both
- Log in with Firefox. No problems.
- Try and login using IE.  No go.

Okay, I’ve done as you directed.

I grabbed the current production release of CodeIgniter, and dx_auth.  I configured both.  I logged in with konqueror and Firefox/Iceweasel and proved out that I could get to the backend screens (as admin).

I cranked up a virtual machine running a pristine new install of XP with IE v6.

And guess what?  It works!

Or, if you prefer - go.

There has to be something special about your environment.  Curiously this is what people have been telling you for some time, though you seem disinclined to work towards a solution.

My environment :
Debian unstable with Linux 2.6.30
KDE 4.3.2
Virtual machine:
    VirtualBox running XP SP3 with IE6
URL:
  http://192.168.1.100/~jedd/binky/

Importantly I have no underscores in my hostname - is this something that has been consistent in your previous problem sites?

My VirtualBox XP environment picks up the (adjusted) time from the localhost, so it’s accurate to within a couple of seconds.  Have you confirmed with your previous problem sites that the time was in sync (or at least very close to being so)?

I mention time and underscores as they appear to be the two common things people have suggested you check - though you have yet to usefully comment whether they apply on your site(s).

Perhaps you could crank up an instance of a broken CI / dx_auth system - tarball it and make it available for me to play with?  I suspect there’s not much benefit there - since I’ve just pulled these things in from public sources and then did minimal configuration work against them - but just to rule it out.  Setting up a VM is a much bigger task, especially as it appears to be a client-end problem.

Are you seeing entries appear in the ci_session table at all?  Analysing the contents of those might help in narrowing down if it’s a time-based problem.  Similarly bumping up the session life to something large (48 hours or so).

I think you just need to start spilling on the details of your environment, if you genuinely want anyone to be able to help you solve this problem.

For those looking for a fix, I have resolved my problem:

I took a few minutes to diagnose the same problems described with CI Sessions and DX Auth.

First, I synchronized both server and client time (both where wrong). Temporarily the problem subsided; however, it mysteriously stopped storing the session. So.. I checked the database and no session or login attempt was being recorded.

Second, I began reading this and other discussions and found that by removing the underscore (_) in the CI config.php file, the problem was resolved.

Original:

$config['sess_cookie_name'] = 'ci_session';

Modification:

$config['sess_cookie_name'] = 'cisession';

I no longer have a problem with sessions in IE8 on WinXP.

For those that attempt to resolve their problem using these methods, please post your results, good or bad.  By the way… uber-fan of CI.

First, I synchronized both server and client time (both where wrong).

...

Second, I began reading this and other discussions and found that by removing the underscore (_) in the CI config.php file, the problem was resolved.

Who could have guessed?

i also encountered some session bugs which almost made me anne of my mind 😊

i had setup sessions for ‘localhost’ and was using 127.0.0.1 and was wondering WHY it
didnt recognize the the cookies 😊 (my fault :D)

Hi,

I’ve also encountered session issues using CI session library, specifically when I upload to my remote host.

Details:

1. I develop the website on my localhost, everything works well - first time using CI, I fall in love. (Big MVC fan)

2. I upload the website to my remote server, everything works great, accept I am attempting to use sessions to save some data when I get a return response from Paypal, which was an attempt on its own to get working (Paypal requires you to be able to receive $_GET variables, I’ve finally managed to work this out but CI really could use some better documentation / variations when you are required to receive $_GET, anyway.. separate story)

3. After setting the session then redirecting to the next page (/checkout/review) I find the session is empty, only on ONE of the THREE servers I have tested. (Although I know sessions and cookies both work using native php cookies/sessions)

4. So, here is some pseudo code logic:

// cURL request to payapl, specifying a return url, dollar amount, etc.

// I am not on paypals page, user logs in/specify's credit card, and hits submit

// cURL request returns me to the returl url, with query string variables ($_GET) pertaining to information that I need. (A special token to relate to this transaction)

// From here, I send another cURL request, using the previous information sent from paypal and the redirect to a 'review payment' page, with the returned results from paypal because I need the return info, i store it into a session by doing the following:

$this->session->set_userdata('paypal_result', $result);
        redirect('./checkout/review/');

// At this point I am on the review page, and there is nothing in the session data, although $result is full of data (print_r($result), its an array..)

// here is an overview of that entire section of my code, all within the same controller - checkout.php


// AUTH REQUEST
function auth()
    {
        // do the paypal stuff, lets initialize an auth request, with an amount (everything else is static!)
        $this->paypal->init_authorization(50);
        $result = $this->paypal->request();
        
        // check for an error
        if($this->_err_check($result["ACK"], $result))
            return;
        
        // if the result is a success, redirec to paypal
        if($result["ACK"] == "Success")
            header("Location: " . $this->paypal->get_param("PAYPAL_LOGIN") . urldecode($result["TOKEN"]));

    }


// RETURN URL

    function returnurl()
    {
    
        // initialize paypal variables for the review
        $this->paypal->init_payment_review($_GET['token'], $_GET['PayerID']);
        
        // post the request to paypal and retreive the results
        $result = $this->paypal->request();
                
        // check for an error
        if($this->_err_check($result["ACK"], $result))
            return;
        
        // set the result in flash data, because we are going to redirect to a new page to remove the ugly $_GET requests from the url.
        $this->session->set_userdata('paypal_result', $result);
        redirect('./checkout/review/');
    }



// REVIEW PAYMENT BEFORE PROCEEDING

function review()
    {
        // get the flash data for the user to review.
        $data = $this->session->userdata('paypal_result');
        
        // set the flash data again, because we will need it when we process the payment.
        $this->session->set_userdata('paypal_result', $data);
        
        echo '<pre>REVIEW
';
        print_r($data);
        echo '<a href="/csnq/checkout/process/">Click here to make sure that you can get the most out of life!!</a>';
        echo '</pre><p>‘;<br />
    }

Some browser fact to note:

  - It fails in IE and Firefox and Chrome

So, this all works fine on my localhost AND I’ve also uploaded it to one other remote server, both are working. Only the server this website needs to be hosted on refuses to let the sessions work.

The phpinfo page for the server which is NOT working, can be found at http://www.darklite.com.au/phpinfo.php

These are my session settings in config

$config['sess_cookie_name']        = 'ci_session';
$config['sess_expiration']        = 7200;
$config['sess_encrypt_cookie']    = FALSE;
$config['sess_use_database']    = FALSE;
$config['sess_table_name']        = 'ci_sessions';
$config['sess_match_ip']        = FALSE;
$config['sess_match_useragent']    = TRUE;
$config['sess_time_to_update']     = 300;
$config['cookie_prefix']    = "";
$config['cookie_domain']    = "";
$config['cookie_path']        = "/";

Any help on this would be much appreciated! Thanks!

Ok I’ve resolved the issue I was having after reading a post over at http://ellislab.com/forums/viewthread/100916/

By setting my cookie_domain option to the name of my domain, it allowed me to save sessions (because CI uses cookies to save the session, and this server must require you to explicitly outline the cookie domain)

So for anyone else having troubles like this, What fixed the problem:

$config['cookie_domain'] = '';

Change to

$config['cookie_domain'] = 'darklite.com.au'; // whatever your domain name is