Problem with Session IDs

Is there a better way?

[AprilS]

We have been using a PHP shopping cart system for a couple years now which we built in house. It works like a charm 95-98% of the time - but it does have its flaws - and I have to say almost every single one of those flaws is due to PHP relying on the Session ID.

Our Problems:
1) If we notice the visitor is a bot...we don't include the session id in our links. I will never be able to keep up with the bot user agents so I want to stop using session ids in the links.
2) One of our biggest problems is when a customer is shopping online and adding items to their cart, and while adding another item (doesn't matter how many items they've added - its random) to their cart they will no longer have the previous items in their cart because they are now using a new session id. For the longest time I though our customers were crazy until I finally experienced it (took a year for me to experience it). It is totally random...it seems like the Session ID will randomly switch to a new Session ID. Again...I would say 95-98% of the time it works like a charm...but then again I can't be possitive how many customers this has happened to...as most of them would just leave and not inform us.

Here is a little info about our configuration:
PHP Version 4.3.1 [FreeBSD 4.4,Apache ]
the complete site is dynamic using PHP and on every page we include a file that does:
session_start();
$SID = session_id();
session_register("SID");

Is there a better way? I’m so overworked, that it is probably something simple. I’m asking for help because each time I get a spare second to look into this issue some other issue comes up that I have to deal with.

[trillianjedi]

Can't you use a cookie instead?

TJ

[AprilS]

I've thought of that, but we can't rely on cookies as not all customers have cookies enabled in their browsers. We want to make sure as many customers can shop on our site as possible.

[Nick_W]

Try this:
[webmasterworld.com...]

Nick

[AprilS]

Yes, we already do this. You should SEE the list of bots we have identified, but user agents are always changing and I just don't have the time to identify them. I would rather get away from using session variables in the URL and use them seemlessly in the backround... (if I could just figure out how do to this properly). Again... doing a session_register works the majority of the time... but for some reason... at random times... the visitor will be given a new session id.

I hope this makes my objective more clear. :D

[AprilS]

Ok, I was just reading another post, it didn't talk about this issue... but it gave me an idea. I opened my browser and turned OFF cookies. Then I proceded to browse our site. I noticed the server held on to the session id UNTIL I clicked on a secure link "https"...at this point the session ID changed! Now that I found this out...does anyone know WHY php started a new session? it keeps generating new session ids when I go back and forth between secure and non-secure portions of our site (http: and https)? I'm not sure how this corolates with the browser cookies being turned off.

[Nick_W]

>>at random times... the visitor will be given a new session id

Always baffles me too! - Even with cookies ON I sometimes get a session id appended. Which is why I've taken to ditching sessions and managing that data with a cookie and a db.

I know some have them turned off but it's a reasonable trade off IMO

Nick

[AprilS]

But that is just it... I don't want to exclude ANY customers - especially if they don't have cookies turned on...that would be just throwing away potential $$$. Does anyone know what I should do?

[Asandir]

I think what is supposed to happen is that php/apache cannot reference your session id in your cookie until you visit the site again - the same with all cookies. You aren't able to access the cookie you're just set in a php script until another page is visted, or the current one is reloaded. Well, I'm pretty sure - but someone else will set me right.

Ie, if you browse the page, all the links on the first page will have the sid appended automatically by apache. But the page did set a sid cookie - it's just not available until the next visit. If you reload the page, the links should return to normal.

My guess about the https problem - when you switch from http to https, you're actually connecting to another vhost on the server (http-ssl is on port 443). That would be the first place I'd start looking at for "hiccups".

[Asandir]

Oh, forgot to add - I custom wrote a cart, and I decided that apart from logging and tracking, there was no point starting a session until the user got interactive.

So as soon as a visitor tried to add something to their cart, it would start a session and set the cookie. As the add-to-cart link was in my /cart directory, and robots.txt banned the bots from there, I have no issues with spiders and sessions...

[AprilS]

https doesn't use a separate vhost, its just using a different port.

I really like the idea of only tracking customers once they get serious...but we designed our site to keep track of our customers so we can learn their shopping habbits.

<sigh>This is just a mess. It just seems like there should be a way to get Apache or PHP to track a customers session id in the backround WITHOUT ever auto-appending it to URLs or having to set cookies.