Greetings... A problem I appear to be having with FSSession. I mentioned it a while ago, and got a reasonable response. However, now I believe it's a threading problem. When uses log in on my page, I set info in their FSSession details. This info is checked in the standard header and it renders accordingly. However, sometimes a valid login won't produce the correct header. This is easily fixed by selecting any page and going there... Everything renders correctly then. This is why i think it's a timing problem with threads. Now, having had 0 experience with threads in python (and having done well to avoided needing it in all other languages ;) i can't see where in the FSSession object this problem might be occurring. In fact, the logic of it only holds because it's happening. Otherwise I would have thought the session details would be written as the FSSession dtml-calls occurred. Any ideas? -- Have a better one, Curtis. <dtml-var standard_work_disclaimer>
On Tue, 11 Apr 2000, Curtis Maloney wrote:
In fact, the logic of it only holds because it's happening. Otherwise I would have thought the session details would be written as the FSSession dtml-calls occurred.
FSSession stores session data in a volatile attribute and only commits them on disk if the transaction successfully commits. It would be innefficient to access the disk everytime there is an update to the FSSession object not to mention that rolling back transactions would be a nightmare. A consequence of this is that if a user with the same Session UID tries to access his session info from a different thread before the first commits (as it would happen if a user points two browsers on Zope at the same time.... darn I suppose it could happen with frames too) then the second thread will not see the additions. I considered this possibility 'unnatural' but then again I did not think about frames then. What does your log in code look like? Pavlos
On Wed, 12 Apr 2000, Pavlos Christoforou wrote:
On Tue, 11 Apr 2000, Curtis Maloney wrote:
In fact, the logic of it only holds because it's happening. Otherwise I would have thought the session details would be written as the FSSession dtml-calls occurred.
FSSession stores session data in a volatile attribute and only commits them on disk if the transaction successfully commits. It would be innefficient to access the disk everytime there is an update to the FSSession object not to mention that rolling back transactions would be a nightmare.
Ok.. makes sense.
A consequence of this is that if a user with the same Session UID tries to access his session info from a different thread before the first commits (as it would happen if a user points two browsers on Zope at the same time.... darn I suppose it could happen with frames too) then the second thread will not see the additions. I considered this possibility 'unnatural' but then again I did not think about frames then.
I'm not using frames, nor is anyone using two browsers at once (of this i can be almost 100% certain, and I know it's happening when nobody else has access to the box.)
What does your log in code look like?
The user login entry boxes are part of the standard header, so the check is done on every page. If the user is already logged in, their details are shown, instead of the login boxes. This is where the problem shows. Here is my verify document, which is called when the user hits the Login submit button: <dtml-var standard_html_header> <dtml-in "sqlPasswordCheck(user=username, company=company)"> <dtml-if "passwd == Password"> <dtml-call "FSSession.set('UserName',username)"> <dtml-call "FSSession.set('ID',company)"> <dtml-call "FSSession.set('Permissions', Permissions)"> <dtml-var "RESPONSE.redirect(HTTP_REFERER)"> </dtml-if> </dtml-in> <h2>Incorrect Login Attempt</h2> <p> <a href="<dtml-var HTTP_REFERER>">Try Again.</a> </p> <dtml-var standard_html_footer> So, if the user logs in correctly, they are redirected to whence they came, which would normally shunt them off to another page. Would I be correct in assuming that the cookie being set is a good indicator of a new transaction beginning? or one ending? -- Have a better one, Curtis. <dtml-var standard_work_disclaimer>
+----[ Curtis Maloney ]--------------------------------------------- | | <dtml-var standard_html_header> | <dtml-in "sqlPasswordCheck(user=username, company=company)"> | <dtml-if "passwd == Password"> | <dtml-call "FSSession.set('UserName',username)"> | <dtml-call "FSSession.set('ID',company)"> | <dtml-call "FSSession.set('Permissions', Permissions)"> | <dtml-var "RESPONSE.redirect(HTTP_REFERER)"> | </dtml-if> | </dtml-in> | <h2>Incorrect Login Attempt</h2> | <p> | <a href="<dtml-var HTTP_REFERER>">Try Again.</a> | </p> | <dtml-var standard_html_footer> try this <dtml-if "sqlPasswordCheck(user=username, company=company)"> <dtml-in "sqlPasswordCheck(user=username, company=company)"> <dtml-if "passwd == Password"> <dtml-call "FSSession.set('UserName',username)"> <dtml-call "FSSession.set('ID',company)"> <dtml-call "FSSession.set('Permissions', Permissions)"> <dtml-var "RESPONSE.redirect(HTTP_REFERER)"> </dtml-if> </dtml-in> <dtml-else> <dtml-var standard_html_header> <h2>Incorrect Login Attempt</h2> <p> <a href="<dtml-var HTTP_REFERER>">Try Again.</a> </p> <dtml-var standard_html_footer> </dtml-if> -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|
On Wed, 12 Apr 2000, Andrew Kenneth Milton wrote:
+----[ Curtis Maloney ]--------------------------------------------- | | <dtml-var standard_html_header> | <dtml-in "sqlPasswordCheck(user=username, company=company)"> | <dtml-if "passwd == Password"> | <dtml-call "FSSession.set('UserName',username)"> | <dtml-call "FSSession.set('ID',company)"> | <dtml-call "FSSession.set('Permissions', Permissions)"> | <dtml-var "RESPONSE.redirect(HTTP_REFERER)"> | </dtml-if> | </dtml-in> | <h2>Incorrect Login Attempt</h2> | <p> | <a href="<dtml-var HTTP_REFERER>">Try Again.</a> | </p> | <dtml-var standard_html_footer>
try this
<dtml-if "sqlPasswordCheck(user=username, company=company)"> <dtml-in "sqlPasswordCheck(user=username, company=company)"> <dtml-if "passwd == Password"> <dtml-call "FSSession.set('UserName',username)"> <dtml-call "FSSession.set('ID',company)"> <dtml-call "FSSession.set('Permissions', Permissions)"> <dtml-var "RESPONSE.redirect(HTTP_REFERER)"> </dtml-if> </dtml-in> <dtml-else> <dtml-var standard_html_header> <h2>Incorrect Login Attempt</h2> <p> <a href="<dtml-var HTTP_REFERER>">Try Again.</a> </p> <dtml-var standard_html_footer> </dtml-if>
Ok... I think I may have been a little unclear here. It is NOT reporting the login attempt failing. So, this code determins that the user is valid, and sets the FSSession data. However, the next page it sends to _sometimes_ doesn't think UserName exists, using the following code, which is from the standard_html_header: <dtml-if "FSSession.has_key('UserName')"> <form action="<dtml-var "PARENTS[_.len(PARENTS)-2].id">/logout_html"> <h3>User Name:</h3> <dtml-var "FSSession['UserName']"><br> <h3>Company:</h3> <dtml-var "sqlGetCompanyName(company=FSSession['ID'])[0].CompanyName"><P> <input type="submit" value="Logout"> </form> <dtml-else> <form action="verify_html"> <h3>User Name:</h3><input type="text" name="username" size="8"><br> <h3>Company ID:</h3><input type="text" name="company" size="8"><br> <h3>Password:</h3><input type="password" name="passwd" size="8"><P> <input type="submit" value="Login"> </form> </dtml-if> -- Have a better one, Curtis. <dtml-var standard_work_disclaimer>
On Wed, 12 Apr 2000, Curtis Maloney wrote:
However, the next page it sends to _sometimes_ doesn't think UserName exists, using the following code, which is from the standard_html_header:
<dtml-if "FSSession.has_key('UserName')">
Curtis - I do assume that you have called <dtml-call FSSession> before that Pavlos
On Wed, 12 Apr 2000, Curtis Maloney wrote:
So, if the user logs in correctly, they are redirected to whence they came, which would normally shunt them off to another page. Would I be correct in
I believe that a RESPONSE.redirect will first commit the current transaction before redirection (I should check the source code), in which case the FSSession contents would be available.
assuming that the cookie being set is a good indicator of a new transaction beginning? or one ending?
Yes, good idea. A cookie will only be set when a transaction commits. Check if the cookie is there after the redirection occurs. Pavlos
On Thu, 13 Apr 2000, Pavlos Christoforou wrote:
On Wed, 12 Apr 2000, Curtis Maloney wrote:
So, if the user logs in correctly, they are redirected to whence they came, which would normally shunt them off to another page. Would I be correct in
I believe that a RESPONSE.redirect will first commit the current transaction before redirection (I should check the source code), in which case the FSSession contents would be available.
assuming that the cookie being set is a good indicator of a new transaction beginning? or one ending?
Yes, good idea. A cookie will only be set when a transaction commits. Check if the cookie is there after the redirection occurs.
Well, being the curious (and maybe a little paranoid :) type, I have 'ask' set on my cookie options, so I see every time it tries to set one. When you log in in this circumstance, two cookies get set (once for the verify page, once for the page it redirects you to). Oh, and yes... <dtml-call FSSession> is in the standard_html_header, since it uses FSSession data (as i showed previously) So.. If the cookie means it IS commiting, i'm left wondering why the information isn't showing up. When a redirect occurs, is it possible the browser is making the new request on another thread, which _sometimes_ beats out the 'commiting' thread? Or is commiting completed before the cookie is set?
Pavlos
-- Have a better one, Curtis. <dtml-var standard_work_disclaimer>
On Thu, 13 Apr 2000, Curtis Maloney wrote:
When you log in in this circumstance, two cookies get set (once for the verify page, once for the page it redirects you to).
This is what I expected as long as the two cookies have the same SessionUID. If not then that is the problem.
So.. If the cookie means it IS commiting, i'm left wondering why the information isn't showing up. When a redirect occurs, is it possible the browser is making the new request on another thread, which _sometimes_ beats out the 'commiting' thread? Or is commiting completed before the cookie is set?
As far as I understand calling RESPONSE.redirect, causes the RESPONSE object to emmit the neccessary headers for redirection. In other words the transaction has already finished, commited, and the client receives the redirection headers before the client places the next request. The redirected request can be served by any thread. Nevertheless as the original transaction has already commited the FSSession data should be available to the new request. I have recreated your set up (if I am off let me know) and it works fine for me. My standard_html_header looks like: <HTML><BODY> <dtml-call FSSession> <dtml-if "FSSession.has_key('test')"> <P><dtml-var "FSSession['test']"> </dtml-if> <dtml-if flag> <dtml-call "FSSession.set('test','Hi')"> <dtml-call "RESPONSE.redirect('method2')"> </dtml-if> and my method1 and method2 contain <dtml-var standard_html_header> nothing <dtml-var standard_html_footer> if I call /Test/method1?flag=1 I get redirected to /Test/method2 which displays Hinothing as expected. Check if the two SessionUIDs in the two cookies match or use showSession in the FSSession directory to examine the contents of the session file. Regards Pavlos
participants (3)
-
Andrew Kenneth Milton -
Curtis Maloney -
Pavlos Christoforou