PHP Session ID - randomonly resets

works great most of the time... PLEASE HELP

[AprilS]

I'm having a problem with the PHP session id. It works great most of the time - but every now and then a user will be assigned a new session id.

Here is an example - A customer shops around and adds items to their cart...and then lets say they add an item and then all of a sudden (to their eyes) their old cart items are gone and they now just have the most recent item. Now when I trouble shoot it I can see that they no longer see their items because they were assigned a new session id. But here is the weird thing, let say the go somewhere else on the site and then click on the link to check the contents of their cart... this time they see their OLD items again. At first I thought this was isolated to IE...but its not - I also see it in Netscape, mozilla, Opera...etc. Keep in mind that this normally does not happen. Normally our site works GREAT and no one has a problem while shopping.

Does anyone have a CLUE why session IDs are being reset/changed in the middle of a session?

I do this on every page:
session_start();
$SID = session_id();
session_register("SID");

I'm sure its something simple - but the fact that it works flawlessly most of the time is really messing me up.

Thanks in advance for any help!

[jatar_k]

To be honest I am not sure. Any other info?

Anyone else have any ideas?

[coopster]

One that comes to mind right off is the sub-domain issue. If your session cookie is being set for the domain "mydomain.com" and then somewhere during your session there is a link to "www.mydomain.com", it is going to set a new cookie. The two are quite different. Check the cookies in the browser for those folks that are having this issue to see if they do indeed have two separate cookies.

How could this happen? Well, the

session.cookie_domain

configuration directive is set to nothing at all by default in

php.ini

. Your session will grab the current domain when it sets the cookie. To overcome this issue, you can set your session cookie parameters before any sessions are started:

session_set_cookie_params('', '/', '.mydomain.com', 0);

and any subdomains, including "www.mydomain.com" will be included in the session.

Just one thought...

[ergophobe]

I have some ideas, but I suppose you meant related to this topic ;-)

All I can do is free associate...

- your site is split across multiple domains somehow (credit card processing for example) and cookies are not shared across domains. That should never work.

- they see their old items because a page is cached. When they get their old cart back, do they maintain it if they add yet another item?

- user is browsing in multiple windows and visits some other site that sets a session id. Old cart available because of caching, but session is dead.

- multiple servers handling the load or switch to another server for https and one server does not have register_globals on. Have you tried it without using session_register() which is deprecated anyway (indirectly since register_globals is deprecated).

[ergophobe]

Coopster beat me to it again. His theory on why you might have multiple domains makes more sense than mine, since in my scenario it should be true for all users.

Tom

[lorax]

Does it happen while in secure mode and if so might you be using OpenSSL or a Shared SSL Cert?

[AprilS]

Thank you for the responses.

coopster - the same domain and sub-domain (canonical) is used throughout the whole site

ergophobe
- Our site is not split accross other domains
- The page isn't being cached
- Yes, sometimes at random when they add a new item to the cart, their old items are not there...this is because they have somehow been assigned a new session id and when the cart goes to look that session up in mysql - it doesn't exist yet. However, it is possible to later on hit refresh while viewing the cart or by later going back to the cart and seeing their previous items because the browser is then using the old session id again (ya...boggles me)
- If a customer was browsing another site with a different window...would that really override our session id? It would seem like a major problem as most people browse with multiple windows open at a time.
- regarding your comment about caching again - we require a database lookup each and every time they view or add/delete an item in their cart.
- we are not using multiple servers...just 1

Regarding SSL - I just checked our PHP Info and I see these two things
OpenSSL Support: Enabled
OpenSSL Version: OpenSSL 0.9.6e 30 Jul 2002
_SERVER["SERVER_SOFTWARE"] mod_ssl/2.8.5 OpenSSL/0.9.6a

The issue happens in both the https and http environment.

Does this help at all? I really appreciate you guys helping me with this. I have spent MONTHS trying to research this but have been unsuccesful. I really hope someone can help me out as this is effecting customers/sales as it can be quite anoying to customers when it does happen. Again, I can't say exactly how often it happens. It is quite random - but happens enough to be considered an important problem.

[coopster]

>>However, it is possible to later on hit refresh while viewing the cart or by later going back to the cart and seeing their previous items because the browser is then using the old session id again (ya...boggles me)

Well, to the best of my knowledge, this means that the server is not destroying the session, nor is the session being cleaned up during garbage collection prematurely...

Hey, it might help if you could display the php.ini session configuration directives for the server...

[AprilS]

coopster -
True, I do not "destroy" the session at any point while they are shopping. This is only done when they complete their order.

I believe most of these are set to defaults. Thank you so much for asking to look at these. I have read the comments in the php.ini file and documentation on php.net for php.ini - but not too helpful..

[Session]
session.save_handler = files
session.save_path = /tmp
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.gc_probability = 1
session.gc_maxlifetime = 1440
session.referer_check =
session.entropy_length = 0
session.entropy_file =
;session.entropy_length = 16
session.cache_limiter = private
session.cache_expire = 180
session.use_trans_sid = 1

[ergophobe]

- If a customer was browsing another site with a different window...would that really override our session id?

Geez I'm stupid today! No, of course not. What I was thinking is if there were something on your site like a bulletin board or something that sets a cookie with a session id. This happened to me where an ISPs control panel would screw up sessions on the actual site.

[coopster]

One area you may want to scrutinize is your session.cache_limiter [php.net] directive. I'm not saying this is it, but it is definitely worth digging into. You'll find some good information and links in the User Contributed notes from the link there.

[lorax]

>> Does this help at all?

Not for me... I'm stumped. It seems like everything is as it should be based on what you're telling us. Have you been able to duplicate the issue yourself?

[AprilS]

Yes, I was able to recreate it myself. But for the LONGEST time I didn't have a clue what our customers were talking about (thought they were crazy). For over a year I was unable to recreate the error that we would hear about - and then it just happened one day. I've now experienced quite a few times.

I'm not sure if this is remotely related - but it seems similar so I'll throw it in. We track where customers come from using (getenv("HTTP_REFERER")) - now here is the weird thing - sometimes (random) the HTTP_REFERER is dropped - like the session_register holds it throughout quite a few pages and then will just drop it. Now, I'm not talking about viewers that don't have a referring URL - I'm only talking about ones that come in with a referring URL....sometimes it just gets dropped. Someone could browse through 80 products and checkout and we still have the referer and yet another visitor may browse only 5 product pages and the referrer value gets dropped (no particular page...just random). This happens more often (guessing 25% of the time) - so it is easier to see...but again...I can't find the cause. Either way - it looks like PHP isn't handling sessions well. I'm hoping it is just a misconfiguration that can be easily be fixed. However, I've been trying to track this down for so long - it could be flashing on my screen and I would probably miss it at this point.

Again, any and all help you could provide would be greatly appreciated! :D

[Nova Reticulis]

Why not just drop the session ID support entirely and rely on cookies?

I just had to disable session rewriting in URLs on the web server because our link checking bot stepped into a dynamically generated area of the site, which in turn produced new session IDs all the time (the bot doesn't support cookies). The bot got confused and started travelling every single rewritten URL, entering an endless loop, recording 100,000 URLs and eventually crashing the webserver.

URL rewriting for sessions is a hack. Why use it?

[AprilS]

Relying just on cookies only allows customers who have cookies turned on to shop.... that prevents quite a few people from shopping....lost sales

[atsw]

This might be kind of dumb, but do you have session_start() at the beginning of your pages? I have had problems before where my session id resets when I didn't have session_start at the beginning.