Welcome Guest, Not a member yet? Register   Sign In
Which session library to use? Any suggestions?

Look, I understand IE blows. The whole point of my post is that I'm getting paid to develop a site, and CI's sessions work on every web browser on the planet save IE.

I live in the REAL WORLD. Not some idealist, everyone-adheres-to-standards parallel universe. And, in the REAL WORLD, a statistically significant portion of people still use IE. Hence, I need to pander to these idiots if I want a paycheck. I can't tell a panel of hospital administrators that *my* Code-Igniter-based web site doesn't work because IE is useless. That argument does not fly when these same administrators can turn on their hospital-issued laptops at that meeting and shop at Amazon or Google stuff on IE with no problems whatsoever. According to their logic, it's my fault for relying on CI's session class. And they are right. Furthermore, they're not going to amend their purchase order for my web site with a multi-million dollar overall of the web browsers on all their computers in all their branches, system-wide.

That fact of the matter is: CI sessions don't work reliably on IE. They don't.

I know hardcore CI fans don't want to face it, but nonetheless I will repeat that fact: CI's session library does not work reliably.

You can hand me a laundry list of why CI's session handling routines are superior and more secure. On paper, that looks great. You can poke holes in my referenced websites. Good for you. But in the REAL WORLD, CI's session class simply just doesn't work reliably on IE. I'm looking right at it with my own two eyes so you can not tell me otherwise. You can't. End of story.

Enough with the complaints, here is something helpful:

With some minor tweaking I've gotten the Philsbury hack listed above to work with dx_auth. It replaces CI's 1.7.2's absolutely-confirmed-to-be-faulty session class with PHP's built-in session handling... which is only potentially less secure than CI's session class if your project is hosted on a shared server with people you don't trust. In my scenario, this is not the case. So it's not a problem. To be honest, it rarely is for anyone.

You can find his version here:

Contact me if you want my version. It's in no way ready to be released--I'm still tweaking it while I try to scramble and rectify this Code Igniter session debacle.

I will be interested in looking at it. And I assume there are more.
Could you add it to the CI wiki to share with the community?

[quote author="mrbinky3000" date="1258662836"]
That fact of the matter is: CI sessions don't work reliably on IE. They don't.
You didn't read my link now did you.

If you had spend your time researching why your cookies don't work in IE instead of spending it hacking the session library , you would have come to the conclusion that simply removing the underscore in the cookie name comes a long way.

I was so sure that you wouldn't take my word for it that instead of giving you the obvious answer, I pointed you to the resource where the problem as well as the solution are described by MS themselves. I reckoned you would at least believe the creators of the browser which cause the problem.

I read your page. It contains a long list of why IE's handling of cookies sucks. What it does not contain is the one thing I was looking for: a useful hack to get CI's broken session handling working with IE. Did you not read my post?

Furthermore, your referenced page still doesn't change the fact of the matter that CI's session library does not work. If you know how to create a work-around to make CI work with IE's bad cookes--MAKE ONE.

@shinokada --and the rest of us looking for a solution that works NOW.

I posted a hack that works for me. It's not pretty. Hopefully, others will contribute.



I have used CI Sessions for about N projects now... not one complaint about session related bugs and unstability. And I know with 100% certainty that 100% of the users use Internet Exploding 6/7/8.

So I would say its kind of strange that CI's Session library doesnt work..

Word about PHP's native session. They are secure if the hosting environment is secure Smile 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 Smile

[eluser]Derek Allard[/eluser]
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 Wink 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.


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.


[quote author="mrbinky3000" date="1258768785"]
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.

Quote: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!'.

Theme © iAndrew 2016 - Forum software by © MyBB