CodeIgniter Forums
CodeIgniter Session Problems Thread - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived General Discussion (https://forum.codeigniter.com/forumdisplay.php?fid=21)
+--- Thread: CodeIgniter Session Problems Thread (/showthread.php?tid=24783)

Pages: 1 2 3 4


CodeIgniter Session Problems Thread - El Forum - 11-19-2009

[eluser]mrbinky3000[/eluser]
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:

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

to

Code:
$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.


CodeIgniter Session Problems Thread - El Forum - 11-19-2009

[eluser]thdls55[/eluser]
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.


CodeIgniter Session Problems Thread - El Forum - 11-20-2009

[eluser]Unknown[/eluser]
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.


CodeIgniter Session Problems Thread - El Forum - 11-20-2009

[eluser]jedd[/eluser]
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 ...


CodeIgniter Session Problems Thread - El Forum - 11-20-2009

[eluser]Unknown[/eluser]
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.


CodeIgniter Session Problems Thread - El Forum - 11-20-2009

[eluser]mrbinky3000[/eluser]
@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.


CodeIgniter Session Problems Thread - El Forum - 11-20-2009

[eluser]Colin Williams[/eluser]
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.


CodeIgniter Session Problems Thread - El Forum - 11-20-2009

[eluser]skunkbad[/eluser]
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.


CodeIgniter Session Problems Thread - El Forum - 11-20-2009

[eluser]jedd[/eluser]
[quote author="mrbinky3000" date="1258764488"]
@jedd
Please complain elsewhere.
[/quote]

Ahh, the irony.

Quote: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?


Quote: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)


CodeIgniter Session Problems Thread - El Forum - 11-21-2009

[eluser]jedd[/eluser]
[quote author="mrbinky3000" date="1258787584"]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.
[/quote]

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.