It appears the problem is the call to abandon session.
If I remove "abandon session" the redirect doesn't fail.
As an alternative I tried
abandon response cookie ("ACTIVE4D_SESSIONID")
but that still failed.
To workaround this limitation I have added the code you suggested:
delete session item ("@") `remove any existing session data
and added
set session timeout (0) `in lieu of abandon session
One observation from watching the session monitor:
In some cases if I log back in quickly, it appears that I can reuse the
session. I think this is because the "housekeeper" hasn't run yet, and
the fact that my ACTIVE4D_SESSIONID cookie is still set.
I don't think this is a problem though since I'm reclaiming an empty
session. And because the ACTIVE4D_SESSIONID cookie is still set I
suspect I can only reclaim my old session.
Should I log the abandon session behavior as a bug?
-- Brad Perkins
Brad Perkins wrote:
Aparajita Fishman wrote:
Under 3.0.1b7 we used this code to logout of a web application.
<%
`file: /iopr/auth/logout.a4d
import ("sessauth")
import ("iopr")
import("a4d.web")
import("a4d.web.plus")
import("a4d.utils")
abandon session
abandon response cookie ("IOPR_SID")
abandon response cookie ("IOPR_UID")
redirect ("/iopr/auth/login.a4d")
%>
After upgrading to 4.0.2, when I try to logout I get a Browser error
like:
"Your browser could not fulfill a redirect request. Please click
here <http://128.165.208.5/iopr/auth/login.a4d> to go the intended
destination."
FYI, I'm not sure why you are importing so many libraries when you
aren't actually calling any library methods.
I'm not either :)
If you are checking an item in the session to see if it exists in
order to determine if the session is alive, it isn't enough to use
'abandon session', you have to call 'delete session item("@")' as
well, because the session is not actually deleted until some unknown
time later.
I'll try this.
I recommend using tcpflow or some other packet watcher to see exactly
what traffic is going between the server and the browser. The browser
is not happy with something it is getting from the server.
I haven't gone as low-level as tcpflow, but using LiveHttpHeaders, I
just traced a login and logout on our production system (still
Active4D 3.0.1b7) and the development system (4.0.2). The production
system works.
The primary difference I see between production and development when I
issue the logout redirect is that the production system sends a 303
See Other and the development system sends a 200 See Other
Production
----------
HTTP/1.x 303 See Other
Date: Fri, 27 Oct 2006 14:26:08 GMT
Server: 4D_WebSTAR_S/5.3.3 (MacOS X)
Connection: Close
Content-Length: 202
Content-Type: text/html
Set-Cookie: IOPR_UID=abandoned; EXPIRES=Tue, 30-Nov-1999 14:26:08 GMT;
PATH=/
Set-Cookie: IOPR_SID=abandoned; EXPIRES=Tue, 30-Nov-1999 14:26:08 GMT;
PATH=/
Set-Cookie: ACTIVE4D_SESSIONID=006574ebcb20d5ea7074b2776a135a89;
PATH=/; EXPIRES=Tue, 30-Nov-1999 14:26:08 GMT
Location: /iopr/auth/login.a4d
Expires: Fri, 27 Oct 2006 14:26:08 GMT
Pragma: no-cache
Cache-Control: no-cache
Development
-----------
HTTP/1.x 200 See Other
Date: Fri, 27 Oct 2006 14:29:04 GMT
Server: 4D_WebSTAR_S/5.3.3 (MacOS X)
Connection: Close
Content-Length: 598
Content-Type: text/html
Set-Cookie: IOPR_UID=abandoned; EXPIRES=Tue, 30-Nov-1999 14:29:03 GMT;
PATH=/
Set-Cookie: IOPR_SID=abandoned; EXPIRES=Tue, 30-Nov-1999 14:29:03 GMT;
PATH=/
Set-Cookie: ACTIVE4D_SESSIONID=2182572DE5B8F5D3; PATH=/; EXPIRES=Tue,
30-Nov-1999 14:29:03 GMT
Location: /iopr/auth/login.a4d
Expires: Fri, 27 Oct 2006 14:29:03 GMT
Pragma: no-cache
Cache-Control: no-cache
Some other difference I notice:
* Active4D has shortened the length of the Session IDs, but I doubt
that would have any bearing on this?
* Notable content length differences.
Any ideas?
Thanks,
Brad Perkins
Regards,
Aparajita
_______________________________________________
Active4D-dev mailing list
[email protected]
http://mailman.aparajitaworld.com/mailman/listinfo/active4d-dev
Archives: http://mailman.aparajitaworld.com/archive/active4d-dev/
