Thread

Word about PHP’s native session. They are secure if the hosting environment is secure 😊 Session save path should always be pointed to users own tmp dir, not the server /tmp dir. This alone prevents other sites to see your sites session files as they do not have access to other users tmp dir. Also Suhosin should be installed as that will have options to encrypt sessions(and many other security options too).

Edit: oh yeah and garbage collection has not been an issue for a very long time 😊

mrbinky3000, I’m interested in working with you to permanently resolve any issue of IE rejecting CI’s session cookies. I’ve personally (nor any member of the EllisLab development team) been able to recreate this, but if you search “ie underscore cookie” you’ll see dozens (hundreds) of sites claiming that if the hostname contains underscores then the cookie might be rejected. I’m not sure how this can impact CI per se, but I’d like to dig into it. Do you have a public facing site that I could see that exhibits this behaviour?

I ammend my previous statement - I don’t use CI’s sessions, I use OB Session library available from the Wiki.

2 simple reasons - 1) it keeps database stored session variables private. So if you want to set a session flag of user_is_moron to True, the user won’t know even if they look at their browser’s cookie 😉 No need for encryption

2) Related to 1, if you store session info in a database all it transmits to the user’s browser is the bare minimum of session ID. This makes it easier to retrieve the session ID itself for use in hacky sorts of behaviors, such as switching sessions to allow proper handling of shockwave flash connections, and I don’t see why the client should ever be sent more information in the cookie than that, really.

It Just Works just like CI’s native sessions, only I consider it better in these two respects. I’ve used it on four projects so far without a hitch.

@Derek

Hey, the two websites in question are in complete disarray right now as I try and find a solution to my dilemma. I’m trying to meet two deadlines right now.  As soon as I have some free time, I will set up a new subdomain on my server with a fresh install of 1.7.2 + dx_auth which uses CI sessions.  That’s all I did when I encountered the problem.

I fully understand that the problem COULD be with dx_auth. However, when I replace CI’s session class with one that uses native PHP sessions, the problem goes away.

So, there could be something wrong with my server, there is definitely something wrong with IE 😊  or dx_auth could be to blame.  Regardless,  CI’s session class adds a new layer of application code between the programmer and their intended results.  As we all know, every new layer may add benefits, but it also introduces the potential for new errors.  My question to the makers of CI is, why try and re-write PHP’s rock-solid native PHP session functions?  As PHP improves with every new release and update, it seems—in my opinion—that CI sessions become more irrelevant.

@ everyone

In the mean time, at the request of other forum members who think I was hijacking threads,  I started a new thread dedicated to this issue.  To all those reading this, please to not post personal criticisms or defenses of CI sessions on the new thread.  Obviously, lots of people have no issues with CI sessions.  The following thread is intended to provide solutions to those people who ARE having issues.

http://ellislab.com/forums/viewthread/135722/

Hey, the two websites in question are in complete disarray right now

You can’t revert to a snapshot that demonstrated the alleged bug?

Wow.  That sounds very ... professional.

My question to the makers of CI is, why try and re-write PHP’s rock-solid native PHP session functions?

My question to you is why don’t you just use native PHP sessions, if you’re incapable of setting up a sufficiently stable environment.  It sounds like an easy solution to your alleged problem.  No one is forcing you to use the CI session library, after all.

Telling people that ask you for more information to ‘complain elsewhere’ seems disingenuous - why don’t you just describe your problem in somewhat more detail than ‘It doesn’t work - wah!’.

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.

I did the obvious debugs: 
- checked on other computers to make sure it wasn’t just my computer, got on IM and asked friends to check it out.  Others using IE could not log in.
- I wrote a one-off php script outside of the CI environment that simply sets a cookie and provides a link to another script that reads said cookie.  IE got the cookie just fine.
- I wrote a simple controller to set a session var via CI sessions.  It did not work. Hmm, so it isn’t likely to be dx_auth. Cookie never appeared.
NOTE: I suppose I can try a fresh install of CI without DX auth and see what’s up.  Will try that in the future.
- Double and triple checked the cookie settings in application/config/config.php I used the same settings to set the cookie in my one-off script.  Settings are not the problem.

Resolution:
Switched out CI’s session class with one that uses native php session functions.  Problem went away.

What does this tell me:
- Did I configure something wrong?  Perhaps, though I really doubt it.
- Is it dx_auth’s fault.  Perhaps, but dx_auth works fine with a differentt session class.
- Is there something wrong with the server?  Perhaps.  But unfortunately, I did not set it up and changing the server is not an option for one of the two clients.  And even if it is the server’s fault, that shouldn’t matter in this case.

Regardless of whether or not it’s the server’s fault, my fault, the browser’s fault…  I’m convinced more than ever that CI sessions are not necessary.  Other people have already provided helpful replies stating that they don’t use CI sessions because native sessions are more convenient.  I agree but also argue they are also more reliable.

I realize that no one is forcing me to do anything.  I’m just trying to help people having similar problems with sessions from wasting two days hunting down bugs and arguing with unhelpful people like yourself.

So theres all the reproduction info, mainly for others to read.  I am unsubscribing from this thread.  I will continue to monitor the other thread that I started.

http://ellislab.com/forums/viewthread/135722/

jedd, if you wish to continue your personal attacks, please just PM me and stop polluting both these threads with unhelpful replies.  I wish I had the ability to delete your unhelpful comments.

How can I implement the “remember me” checkbox that most sites have using CI Sessions? because if the checkbox isn’t checked I need to destroy the session when the browser is closed, but I can’t do this (or I don’t know how) with CI Sessions.

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.

*ahum*

simply removing the underscore in the cookie name comes a long way.

*ahum*

Don’t worry n0xie - I’ve already defended your good name (and suggestions), albeit by proxy, at this other, remarkably similar, thread.

I see that mrbinky isn’t around anymore - originally I assumed he’d just set it to ignore my posts, but there’s been plenty of other activity (advice, help, dare I say solutions) posted in the threads he was active in.  Perhaps he became enlightened.

It’s a real shame that the cathartic value of a really good ‘I told you so’ is now just so under-rated, and indeed bordering on socially unacceptable.  I think that’s because the majority of people are now likely to be recipients, rather than deliverers, of a hearty ‘I told you so’.  Obviously it was different when the ratio was in our favour.  The eternal September, and all that.  Oh well, on with the dumbening.

While the I’m not one the back away from a well deserved ‘I told you so’, the point of my whole argument was to push the unknowing in the right direction, lets they learn something new. I’m not entirely sure I succeeded 😉

I’ve launched a site which got pretty many users at the moment, but some users complains on autologout and some can’t login sometimes. I’m not sure which browsers they are using but at least one use IE. I don’t want to update the files right now so the users wont see any errors or such. I removed the underscore in the config file for the session name, do you think this will solve my problem?

Thanks.

‘ve launched a site which got pretty many users at the moment, but some users complains on autologout and some can’t login sometimes. I’m not sure which browsers they are using but at least one use IE. I don’t want to update the files right now so the users wont see any errors or such. I removed the underscore in the config file for the session name, do you think this will solve my problem?

That’s a pretty big question.  ‘Can’t login sometimes’ is a touch vague, and doesn’t necessarily equate to cookie timeout or underscore problems.

It’d be nice to know what version of IE they’re using (IE6 is bordering on criminally evil, f.e., and its behaviour simply can’t be predicted) - and any other funky stuff going on at the app end.

‘ve launched a site which got pretty many users at the moment, but some users complains on autologout and some can’t login sometimes. I’m not sure which browsers they are using but at least one use IE. I don’t want to update the files right now so the users wont see any errors or such. I removed the underscore in the config file for the session name, do you think this will solve my problem?

That’s a pretty big question.  ‘Can’t login sometimes’ is a touch vague, and doesn’t necessarily equate to cookie timeout or underscore problems.

It’d be nice to know what version of IE they’re using (IE6 is bordering on criminally evil, f.e., and its behaviour simply can’t be predicted) - and any other funky stuff going on at the app end.

Yea well that’s all I know, they get logged out randomly. I don’t think they’re using IE 6 since it’s almost dead now? It’s hard for me to show you the code cuz it’s alot, the code adding sessions looks like this:

$this->session->set_userdata('user', $loginOK["user_id"] );
                $this->session->set_userdata('groupname', $loginOK["group_name"] );
                redirect('users');

The code that check the sessions looks like this

$user = $this->session->userdata('user');
        if ( ! empty ( $user ) )
        {
            define('USERID', $user);
            $this->load->model('User_model','User',true);
            $user = $this->User->findSingle(USERID);
            define('USERNAME', $user["username"] );
            define('USERSHOWS', $user["shows"] );
        }
        
        // vilken användargrupp man tillhör
        $group = $this->session->userdata('groupname');
        if ( ! empty ( $group ) )
            define('GROUP', $group);

I had an underscore in the “groupname” session before but removed that aswell. Is there anything else I should think of that might cause the “random logout” issue?

What’s your $config[‘sess_cookie_name’] = ‘cisession’;  set to?

I don’t think they’re using IE 6 since it’s almost dead now?

You’d hope / think so, but talking to a web master a couple of days ago and he reckoned they get about 5-10% of hits from IE6.  And they run a fairly techy web site, so the ‘real’ numbers might be higher.  It’s pretty disturbing no matter which way you look at it.

Oh yeah - underscores in your hostname?

Time is set pretty accurately on the host?