How can I offer both URL-based and COOKIE-based SESSION TRACKING ?

[Programmmer]

Hello,

I have a PHP site where 20% of visitors do not have cookie support.

How can I offer both URL-based and Cookie-based Session Tracking depending on Cookie Support?

In other words, if the user accepts cookies, then we use cookie-based Session Tracking. But if they do not, then we switch to URL-based Session Tracking (I'm assuming using session.use_trans_sid) so that those users can still utilize the site.

I do not want to lose 20% of my users and I do not want a site that is 100% based on URL Session Tracking as that not only poses a security risk (I'm referring specifically to the security risk of a malicious user hijacking another user's Session or having a legitimate user inadvertently send their Session URL via e-mail/IM to a friend) but also certain limitations that I don't want the other 80% of users to have to endure.

Thanks.

[penders]

I have a PHP site where 20% of visitors do not have cookie support.

Just curious... is this 20% of real visitors? Or does it include all site traffic, robots, crawlers, etc.?

As to your main query, does the PHP Manual: Passing the Session ID [uk.php.net] help?

[Programmmer]

Just curious... is this 20% of real visitors? Or does it include all site traffic, robots, crawlers, etc.?

100% real users.

As to your main query, does the PHP Manual: Passing the Session ID [uk.php.net] help?

Not fully because it does not explain how to offer both depending on whether the user supports cookies or not.


Any ideas? Thanks again.

[Status_203]

First page of session: Set up session, set cookie and 302 redirect to a checking page (that has the expected cookie value, and the original request in the url)
Checking page: Record whether the cookie was passed, 302 redirect again back to the original request, with either cookie or URL parameter as relevant.

There are complications of course, including but probably not limited to:
* handling the case of somebody without cookies posting a link with a session id in it - you can track the user agent, originating IP (but beware rotating proxies), timeouts etc.
* checking for bots that you want on the site and whitelist them to be able to request pages without a session. (Amazing how many bots can't handle this!)
* excepting this check for robots.txt. (and maybe some other files)

[enigma1]

The way you support both is by setting always the session id with the urls on the very first page load. You cannot tell in advance if the user is going to accept or block cookies.

Therefore when your code generates the urls/links, you append the session identifier if the session cookie (or whatever cookie you use for the session id isn't set). To get around spiders you could check the UA or verify the rdns belongs to a spider before starting the session.

I'm referring specifically to the security risk of a malicious user hijacking another user's Session or having a legitimate user inadvertently send their Session URL via e-mail/IM to a friend

As a side note that won't help you because you would be accepting the identifier by both cookie and url parameter. You need both in this scenario.

So if you want to be secure you need to get rid of the default PHP sessions and deploy proprietary session code that will include at least a reference to a trusted server variable (for example remote IP) from which you can further verify the session, not just that the identifier was issued by your site but also the IP matches.

[Programmmer]

First page of session: Set up session, set cookie and 302 redirect to a checking page (that has the expected cookie value, and the original request in the url)
Checking page: Record whether the cookie was passed, 302 redirect again back to the original request, with either cookie or URL parameter as relevant.

Status_203, is there anyway to do this without the redirect?

What if I try to set the cookie on the first page (homepage) yet append the Session ID to the URL's just in case, then check to see if the cookie was set correctly on the second page, and if not, then simply set session.use_trans_sid = 1 so it appends the SID to the URL automatically from then on?

So the second page (and all subsequent pages) would contain something like:

if (!isset($_COOKIE['PHPSESSID'])) {
//append SID to URL's automatically
ini_set('session.use_trans_sid', 1);
}
session_start();

Would something like that work?

Certainly there has to be some kind of straightforward way to serve both cookie and cookie-less users in PHP without having to resort to the lowest common denominator (URL-based Session Handling)...

[rocknbil]

It's in that link above,

If this build option and the run-time option session.use_trans_sid are enabled, relative URIs will be changed to contain the session id automatically.

But if you want to do it manually,

you can use the constant SID which is defined if the session started. If the client did not send an appropriate session cookie, it has the form session_name=session_id. Otherwise, it expands to an empty string. Thus, you can embed it unconditionally into URLs.

$mysess = SID;

Basically when you use sessions, the session is connected to the client (browser) via the PHPSESSID cookie set when you run session_start(). No cookies, no connection to sessionid. So it's inherent in PHP there is a way to do this, and that is it. :-) You shouldn't have to use program logic if session.use_trans_sid is enabled.

What you will have to do though is add any session variables you set to the query string via program logic - OR - use the sessionid handle to store temporary session data in a table somewhere (I **think**, maybe PHP appends these to the query string too - these are all reasons I avoid using PHP sessions if at all possible.)

A serious consideration is what to do in respect to S.E.'s because your-url and your-url?sid=34543534253245345 will now get indexed . . . . but first things first.