tags:

views:

115

answers:

4

Hi all,

The application that I am having trouble with is a generic web application... nothing special about the way it handles users. That is to say, I handle user information in the session variable, with the session managed via a cookie.

A client of mine is having an issue whereby the users are logged in and every now and again they are presented with a page for a different user (this is easy to determine because the user's name is at the top of each page). If they click the 'Home' link, everything is fine again, apparently.

Now as far as my PHP knowledge is concerned, it would take some effort to mix this kind of thing up, right? I can't replicate the issue in any of our development environments and as far as I am concerned, like I say, it would take some effort to actually 'share' this kind of session information...

So my question is this: what could be the possible problems? Every time I experienced this before it was due to a 'mis-behaving' proxy server, though they are telling me that they are not proxying the requests.

Is there anything else that I may be missing? Any other possible reasons for this (naturally this could include an issue with my code)?

Thanks...

A: 

Are you presenting users with links that have the session id in them (or other requests that take the session id as a parameter) ?

Ólafur Waage
Not on purpose, no. I guess if the browser is not receiving cookies then it would default to that, though. Would having the session ID in the request make things better or worse do you think?
Narcissus
Worse, because then links can be shared between users with their session_id and they then be logged in to their account. That's what i'm thinking is happening. It might be going on without your knowledge (or the users') some ajax query asking for a session id or something offbeat.
Ólafur Waage
+2  A: 

By the sounds of it, even though your client assures you that it isn't, it still seems like a proxy or caching problem to me. If at all possible, you could add something like a timestamp when a page was generated somewhere near the user field just to make sure the request is up to date.

This way if the page messes up, you have some indication if the page was generated earlier and stored by something on the way. If your ajax results are cached by the browser and your client has multiple people on the same webbrowser, it wouldn't require a proxy to get wacky results.

Another way you could attack this problem is by logging the requests from your client, and checking if you've missed anything. If you play back the requests, do you get the same result?

Can you verify that when you are logged in as user A, and you 'misplace' your session cookie (delete it), can you still get to the information you wanted? If so, there might be something wrong with the way authentication is handled.

Hope this helps!

ylebre
I like the idea of a timestamp on the page form, just for "informational" purposes. This definitely would have helped I think.
Narcissus
+1  A: 

You might want to consider doing some sort of session verification, such as storing the IP address in the session and destroying it if the address in the session and the current user's IP don't match.

Of course, rather than destroying it, you could just force a new session for the user if the IP doesn't match. I think something like this will work:

session_start();

if (isset($_SESSION['ip'])) {
    if ($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
        session_regenerate_id();
        session_destroy();
        session_start();
        $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
    }
} else {
    $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}
R. Bemrose
+1  A: 

So it turns out that the final outcome of this situation, at least, was fairly oddball.

It turns out that the client was using handheld computers to access the application and letting the batteries go flat. This particular device then reset its clock to 2005 when the battery was eventually recharged and it seems as though this led the browser to read certain pages from its cache.

As soon as the clock on the device/s was set correctly, the issue went away.

Thanks to all for the suggestions: I hate trying to debug these caching type issues. I guess, though, that I really should add some headers to try and stop these handhelds caching the data.

Narcissus