Forum Moderators: open
My first thought is that it may be the Sessions i have set on the site, but surely it can't be.
First i should explain the problem.
We have created a site where users need to register/login to be able to use the site fully. Once logged in, we have used sessions so that the machine knows who you are.
As far as i was aware, sessions were browser side. i.e. the session values are not stored on the server, or am i wrong?
Someone (person1) was logged into the site while on the phone to a friend(person2) taking them through it. When the person2 opened the forum, he was already logged in, but as person1.
We have used the same ASP code for numerous other sites and never come across this. I always that that sessions were specific to the users machine, meaning that hundreds of people could be logged in from different machines all around the world, but would never accidentally be given someone elses details.
Im probably not explaining this to well. Has anyone experienced this before?
Webboy
As far as i was aware, sessions were browser side. i.e. the session values are not stored on the server, or am i wrong?
Session id's are *also* stored on the server. So, each visitor should have a session cookie on their computer and a corresponding id must be stored on the server in order to link visitor with the session values.
But, I don't really understand your users problem and can't surmise what the problem could be.
Take amazon as an example, which is site that uses cookies to remember you. If you have been on Amazon,and given your details, then someone else goes onto amazon on the same machine you used, they will see your details on the screen.
Now, my situation is kind of the same. user 2 has visited our new site and found himself being logged in as user 1. The difference being that user 1 and user 2 are at completely different machines, and im using sessions rather than cookies.
Basically when someone logs into our site, there details are checked against a registered users db. If they are who they say they are, a few of there details are stored in sessions, and constantly checked with the database. It also allows us to personailse the site slightly.
We have used this on a few other sites, one of which has 12k + users, and have never had the problem mentioned above.
It was one of our clients who phoned to let us know what has happened. They are not computer savvy at all, and im wondering if user2 has logged in using user 1's details or something silly like that, but either way, i need to find an answer.
Hope this is a better explanation.
Webboy
wondering if user2 has logged in using user 1's details
Either that or it's a code issue. If the users are on two different boxes, then it's not possible for them to share the same Session.
Can your users reproduce this? My guess is No, based on what you have said, unless they used the same login credentials.
I had a feeling that 2 separate boxes couldn't access the same session.
The users have no access to any code, so the only thing i can think of is that they have used the same login, or at some point User 1 has used User 2's machine and the session hasn't quite cleared. Which user 1 claims has never happened.
It is a little frustrating as you will no doubt have expereiced. Not that i am saying the client is at fault, but its hard to keep asking non-web savvy clients exactly what happened incase they think you are judging them in some way. But i do think it is something quite silly has happened.
Oh well, i will keep investigating.
Thanks for confirm sessions for me.....appreciated.
Webboy
The session has a relationship to the client via a cookie.
So, first, get the IP addresses of the two machines involved and then check your log file to verify that they are sending different SessionId cookies. The actual cookie name is (something like) ASPSESSION#######.
If they are the same, then I would suspect that they are both going through the same badly configured proxy server. (of course their IP addresses would probably appear to be the same also)
If they are different, then check your code.
btw - if you don't have easy access to the log files, then you can create a test page for them to hit. Here is code for one I use - it will show all of their server variables:
<%@ Language=VBScript %>
<%
Option Explicit
Dim v
%>
<html>
<head>
</head>
<body>
<table border="1" cellspacing="1" cellpadding="2">
<%
For Each v In Request.ServerVariables
Response.Write "<tr><td>" & v & "</td><td>" & Request.ServerVariables(v) & "</td></tr>" & vbCrLf
Next
%>
</table>
</body>
</html>
I would suspect that they are both going through the same badly configured proxy server
This could be the problem......
The 2 guys that used the site work for the same company, and i think they both connect to the web via the same proxy. However, there have been around 15 - 20 others from the same building and company using the site, none of whom have had any problems.
Interesting....i must look into this.
Webboy
Two things:
1) Place this at the top of each page
<% Response.AddHeader "Pragma", "No-Cache" %>
that might stop the Proxy server (as will stop the browser) from caching if that is the case.
2) Get them to modify the settings on their Proxy to enable session state and disable caching.
I have seen session validation solutions that use IP addresses stored to a database as a way to get around client that have cookies turned off.
If you are using session id's in your url then the two users could have entered the same query string. (Session hijacking) just to screw with you.
The session id is created by the server, some servers create a non-random id.
Every so often, these kinds of issues would arise, but there never really seemed to be any rhyme or reason. The users who expereienced the issues usually could not recreate it either. There were times when I had it occur to me over about a two year period as well, but it was always a surprise and I could not make it happen willingly.
I honestly think it is an inherent flaw in the session state somehow, and was aggravated by the fact that we had a server farm with 9 servers and had to do all kinds of tricks to get the session to persist from one server to another as the user jumped around.
BTW, as others have pointed out, session is a SERVER thing, and only the sessionid is written to a cookie, which dies when the session expires (on logoff, browser close, or specified period of inactivity).
-Moz
You'd need to check this though as its been a while and I can't remember where i read this
