The Old Joel on Software Forum: Part 4 (of 5)

Restoring Sessions (PHP)

I know this is specific to PHP, but I'm just not finding any answers on the PHP websites and message boards, so I thought I'd try here!

After many frustrating hours of trying to configure my site to use sessions, I finally got it configured and working... mostly. I decided to use the session.use_trans_sid option, to avoid the whole cookie thing. The last remaining problem I have is that if I leave the PHP pages that are using the session, then come back, I get a new session and my session variables are gone.

Do any of you have any techniques for maintaining a session, without using cookies? There has to be a way to do this, I probably just haven't come across it yet. Yes, I did RTFM, and I've looked all over the web for tutorials and articles. In my opinion, there seem to be tons of people asking this same question, but I've yet to come across any specific answers. There's plenty of info on how to use a session, with or without cookies, but my question is this...

How do you _maintain_ a session across an entire site without using cookies, when only poritons of said site are using php and the session?

HeyCoolAid!
Tuesday, February 3, 2004

"How do you _maintain_ a session across an entire site without using cookies, when only poritons of said site are using php and the session?"

You don't. And now you know why cookies were invented in the first place.

You should probably avoid using transparent session ids because it introduces additional security issues and makes all your URLs ugly as hell.

Almost Anonymous
Tuesday, February 3, 2004

Hum... what would you recommend instead? I need to avoid cookies since there are so many browsers that may have them disabled. Are there some other ways to do this type of thing?

HeyCoolAid!
Tuesday, February 3, 2004

hey! I know! why dont you use frames? that way the master window can maintain the session info and pass it to the child windows as required.

*snigger*

FullNameRequired
Tuesday, February 3, 2004

> Hum... what would you recommend instead? I need
> to avoid cookies since there are so many browsers
> that may have them disabled.

Are there any browsers that won't let you uncheck the "accept cookies" box? In other words, probably every browser/client might have cookies disabled. But is the "may" a good reason to neglect session cookies at all? Don't believe in the hype that most users disable cookies. The "typical" user might still believe that cookies are something edible...

> Are there some other ways to do this type of thing?

No. Cookies were introduced exactly for this purpose, to slightly overcome the statlessness of HTTP communication. You would have to invent a new mechanism that let's the server identify which session belongs to which client.

But in your case, the solution might be to configure your web server that ordinary HTML pages are parsed by the PHP interpreter as well. Then the session-id rewriting would happen, and the session id won't get lost as long as you stay on this server. You have to be extra careful if you want to rely on trans-id solely. Not all URLs will be rewritten with the appended session id. That's especially true for all JavaScript redirects, and for HTTP redirects as well.

Ben
Tuesday, February 3, 2004

"I need to avoid cookies since there are so many browsers that may have them disabled."

Sorry, but I dont believe that is true. The n00bs who use IE certaintly won't have turned off cookies and the advanced users will selectively allow cookies if they think your site is worth it and not going to do anything malicious.

Dan G
Tuesday, February 3, 2004

So, would using cookies allow the site to maintain the session as the user passes through PHP and non-PHP pages? Sorry if these are dumb questions, but I've never needed to deal with sessions before, so...

HeyCoolAid!
Tuesday, February 3, 2004

Yes, using session cookies make that possible. The session id is stored on the clients computer and sent back on any HTTP request to the originating server. A PHP script picks up the incoming session id value, retrieves the associated session and restores it. The cookie itself is only temporary and gets deleted when the browser is closed.

Ben
Tuesday, February 3, 2004

I don't think this is a real problem, myself, but if I was *required* to address this situation I would figure that any visitor whose HTTP_REFERER is something on my site is probably the same visitor last seen at this IP address.

Now, there are several ways this could be wrong. Maybe there are a lot of people behind a proxy that appear to have the same IP, so everybody's sessions get munged up. Maybe there was a DHCP release and the user is now at a different IP, so he loses his session. Maybe the user wandered off and someone else has come to use the computer. In any such case, the user's session is damaged or gone or just plain wrong.

Since the potential consequences of this being wrong are high and the failure is sometimes difficult to detect, I'd just use cookies. If the user has no cookie, I'd send him one and redirect him to another page. If that page doesn't get the cookie, then you know the user doesn't have cookies enabled and you can say "hey, turn on cookies for this site, here's our privacy policy and here's what you need to do". That way, the user can make an informed decision.

Cookies really are the right answer in this case, so unless you have a REALLY GOOD REASON not to use them, you probably should.

Caliban Tiresias Darklock
Tuesday, February 3, 2004

"I need to avoid cookies since there are so many browsers that may have them disabled."

This isn't true and you've discovered exactly what it isn't true: Any user that doesn't have cookies enabled will be unable to use nearly any site that requires a login.

It's understandable, if you have never used sessions before, to have these concerns. But I'm always suprised by people going out of there way to do things the non-standard way.

Almost Anonymous
Tuesday, February 3, 2004

"I don't think this is a real problem, myself, but if I was *required* to address this situation I would figure that any visitor whose HTTP_REFERER is something on my site is probably the same visitor last seen at this IP address. "

I've been bitten by this. I used cookies for sessions but I added an IP address check to ensure that the session ID hasn't be hijacked. Unfortunately, this caused problems for some people -- some users IP addresses change between requests (they are coming from different proxies). Making this entirely unrealiable.

Almost Anonymous
Tuesday, February 3, 2004

Also some proxy servers strip the HTTP_REFERER header making that unreliable as well.

Damian
Tuesday, February 3, 2004

I think the idea behind non cookie PHP sessions is to pass the sid as a hidden value in your forms - or as an argument in your links. That way, you're doing the equivalent of having the browser sending a cookie... you're just passing it manually instead.

That being said... use a cookie. It's a lot easier, and there aren't many complex web sites that will allow you to operate without cookies.

Try hotmail, for instance, without cookies and see what happens.

dir at badblue dot com
Tuesday, February 3, 2004

On additional comment:

You can test to see if the user supports cookies. Set a session variable, and if it doesn't propagate where you expect it to, then the user doesn't have cookies enabled. Send them to a nice page explaining the situation.

Almost Anonymous
Tuesday, February 3, 2004

Depends upon what information you want to store for the Session. If its simply to track a client or verify if the user is logged-in or not, then cookies is the best way to go. Creating and maintaining sessions at your end adds significant overhead for you.

We use sessions for our CGI based application and cannot use cookies due to client requirements. We need to store some information corresponding to each session. This information can change as the user performs operations. So we create a session the first time a user accesses the site, store it at the server end (along with the session specific information), and maintain the session ID in the form and pass it along with each request to the CGI.

However, if you go with similar approach, be warned of the following issues:

1. Security - Entire URL hijacking (GET or POST) becomes much simpler for any malicious user. By submitting the same URL again, the contents of the Web page can be seen. So if security is a concern, implement some custom algorithm to verify the validity of the URL or go in for HTTPS.

2. Load Balancing - Since the session information is stored on the Web Server, so Load Balancing becomes a nightmare. You shall have to devise some mechanism to share the session information between the Web Servers.

HTH

T-90
Wednesday, February 4, 2004

You can begin to resolve the load balancing issues by having the sessions stored in a database separate to the web servers. If the web servers are distributed then yoiu can either have regional information to categorise the session ids or you can replicate from the database.

Session ids can work with or without cookies, but a cookie on its own doesn't validate the session id, it might be left over from some long past session. The validation has to be pessimistic, ie you're more likely to get a new session id than not.

Simon Lucy
Wednesday, February 4, 2004

Thanks so much for all the comments guys. That helps me make a more informed choice on setting up my session based pages. I think you're all right... I'll just go with cookies, and send the user to an explaination page if they have them disabled.

HeyCoolAid!
Wednesday, February 4, 2004

"A visitor accessing your web site is assigned an unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL."

From the php site. You don't need to use cookies. Those who have cookies will not have the id in the url otherwise they will. If you don't use ssl then you have no security so using cookie is only seemingly better.

Personally I've always done sites without the need for cookies because I NEVER get such a requirement so I do what I want. If someone leaves the site and comes back then they have to login again. If a user accepts cookies and hasn't closed their browser then there session is rebuilt upon returning to the site and providing the cookie. So it is easier if you use cookies and works if you don't.

Me
Wednesday, February 4, 2004