Greetings, I'm using FSSession to store login details about visitors to our site. It is important that users only be able to see their own data (of course). Today, however, I find out that some mistakes have been happening. People are finding themselves logged in when they haven't yet, and others finding they're logged in as someone else. This is, obivously, a problem. I cannot see how this could be happening, since the Session ID is stored in a cookie, which should be unique to the client. I am using: Zope 2.1.6 on Solaris 2.7 FSSession 0.4.0 Have a better one, Curtis.
On Fri, 25 Aug 2000, Curtis Maloney wrote:
Greetings,
I'm using FSSession to store login details about visitors to our site. It is important that users only be able to see their own data (of course).
Today, however, I find out that some mistakes have been happening. People are finding themselves logged in when they haven't yet, and others finding they're logged in as someone else. This is, obivously, a problem.
I cannot see how this could be happening, since the Session ID is stored in a cookie, which should be unique to the client.
I am using:
Zope 2.1.6 on Solaris 2.7 FSSession 0.4.0
Further details: Some internal testins has shown that is User A logs in with IE, and User B opens the page fresh (from another machine) they will be logged in as User A. But if User A logs in with NS, this doesn't happen. I am really confused as to what's going on.... My only thoughts are that FSSession is perhaps getting confused by Apache, but surely it would re-issue the same Session ID the request came in with? Curtis
On Fri, 25 Aug 2000, Curtis Maloney wrote:
But if User A logs in with NS, this doesn't happen.
I am really confused as to what's going on....
Me too!
My only thoughts are that FSSession is perhaps getting confused by Apache, but surely it would re-issue the same Session ID the request came in with?
SessionUID is a combination of a time stamp in seconds and a random integer between 1 and some billions. I just tested the behaviour of the random generator under multiple threads and it seems to be ok. So I suppose there is close to zero chance of two requests obtaining the same SessionUID. During load time FSSession gets SessionUID from a cookie if it exists. The only way I can see what you describe happening is in a situation where two or more threads share the same volatile attributes, which as far as I know is not the case. ZODB creates separate copies of each object in each individual thread and nothing is really shared apart from global variables and class (not instance) attributes. I will do some tests ... Puzzled Pavlos
On Fri, 25 Aug 2000, Curtis Maloney wrote:
Greetings,
I'm using FSSession to store login details about visitors to our site. It is important that users only be able to see their own data (of course).
Today, however, I find out that some mistakes have been happening. People are finding themselves logged in when they haven't yet, and others finding they're logged in as someone else. This is, obivously, a problem.
I cannot see how this could be happening, since the Session ID is stored in a cookie, which should be unique to the client.
This is very weird indeed. Nobody has ever reported a similar problem. Can you send me the DTML method that calls the FSSession? Pavlos
On Fri, 25 Aug 2000, Pavlos Christoforou wrote:
On Fri, 25 Aug 2000, Curtis Maloney wrote:
Greetings,
I'm using FSSession to store login details about visitors to our site. It is important that users only be able to see their own data (of course).
Today, however, I find out that some mistakes have been happening. People are finding themselves logged in when they haven't yet, and others finding they're logged in as someone else. This is, obivously, a problem.
I cannot see how this could be happening, since the Session ID is stored in a cookie, which should be unique to the client.
This is very weird indeed. Nobody has ever reported a similar problem. Can you send me the DTML method that calls the FSSession?
Yes. Very weird. I'm not doing anything fancy. <dtml-call FSSession> is in the standard_html_header. Once the users name/password has been verified from the db, i use: <dtml-call "FSSession.set('ReturnerID',ReturnerID)"> to set the value, and test if the user is logged in with : <dtml-if "FSSession.has_key('ReturnerID')"> Logging out works fine, with: <dtml-if "FSSession.has_key('ReturnerID')"> <dtml-call "FSSession.delete('ReturnerID')"> </dtml-if> This was aparently working fine for quite some time (about a month of public usage), until last week. We have examined logs, and seen that one person accidentaly used the system under someone elses ReturnerID, and then rectified their mistake.
Pavlos
I really would rather continue using FSSession, as it has worked fine for me in the past, and I find it very simle to use. It would also save me from having to totaly rewrite the site. (o8 Then again, I am considering using Zope level user authentication in the next revision of this site, but that is already planned to be a major overhaul. Really, I just want to know what's going wrong... Have a better one, Curtis
On Mon, 28 Aug 2000, Curtis Maloney wrote:
</dtml-if>
This was aparently working fine for quite some time (about a month of public usage), until last week. We have examined logs, and seen that one person accidentaly used the system under someone elses ReturnerID, and then rectified their mistake.
If he did rectify the mistake then that should not have resulted in a problem. In any case the problem should have been isolated to that user only. Could it be that the cookie is cached somewhere? I am not familiar with the underlying pricinciples of the apache Proxy directives. Pavlos
On Tue, 29 Aug 2000, Pavlos Christoforou wrote:
On Mon, 28 Aug 2000, Curtis Maloney wrote:
</dtml-if>
This was aparently working fine for quite some time (about a month of public usage), until last week. We have examined logs, and seen that one person accidentaly used the system under someone elses ReturnerID, and then rectified their mistake.
If he did rectify the mistake then that should not have resulted in a problem. In any case the problem should have been isolated to that user only. Could it be that the cookie is cached somewhere? I am not familiar with the underlying pricinciples of the apache Proxy directives.
The user 'rectified' the problem by submitting the request again under their own ID. I don't know when/how they noticed, and am not able to contact them for further comment. As for the cookie being cached, I don't know. It is possible, as I said, that Apache is causing problems. ProxyForward means that when a URL matches a rule, it will be 'forwarded' to another server, and the returned page issued as if from Apache.
From the benchmarks I've seen, this is the fastest way to run Zope. However, I can see how it could confuse Zope into thinking two different users requests are from the same machine, since all the requests are coming from Apache. However, I am hoping (going to check on this, of course :) that the smart folks at Apache have made it 'proxy' properly, to avoid this sort of problem.
Pavlos
Curtis
On Fri, 25 Aug 2000, Curtis Maloney wrote:
Today, however, I find out that some mistakes have been happening. People are finding themselves logged in when they haven't yet, and others finding they're logged in as someone else. This is, obivously, a problem.
Warning! Shot in the dark ahead. :-) Is it possible that your visitors who are experiencing this problem are sitting behind a proxy that is improperly caching their cookies. I've seen something like this where you could log in to zope.org, go to a different machine and find that you were logged in there too. -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.k12.mn.us/ | http://www.zope.org/ W. St. Paul, MN | | http://slashdot.org/ wilson@visi.com | <dtml-var pithy_quote> | http://linux.com/
On Sat, 26 Aug 2000, Timothy Wilson wrote:
On Fri, 25 Aug 2000, Curtis Maloney wrote:
Today, however, I find out that some mistakes have been happening. People are finding themselves logged in when they haven't yet, and others finding they're logged in as someone else. This is, obivously, a problem.
Warning! Shot in the dark ahead. :-)
Is it possible that your visitors who are experiencing this problem are sitting behind a proxy that is improperly caching their cookies. I've seen something like this where you could log in to zope.org, go to a different machine and find that you were logged in there too.
Not something I hadn't considered. But I dismissed it fairly quickly, as I saw the behaviour displayed on two machines in house, which do not use a proxy. What I _have_ considered, tho, is that Apache, which is set in ProxyForward mode, might be confusing the issue somewhat.
-Tim
Curtis.
participants (3)
-
Curtis Maloney -
Pavlos Christoforou -
Timothy Wilson