| Author |
 Topic  |
|
|
paulnoe
Starting Member
USA
48 Posts |
 Posted - 21 August 2003 : 11:00:09
|
I'm trying to make sure that each of my asp pages check to see if a user's session has timed out. I've tried this code and tested it and it doesn't seem to work.
If Session.Timeout = True Then
Response.Write ("Your session has timed out. Please <a href='Loginpage.asp'>login</a> again.")
End If
Is there something obvious that I'm missing? Thanks! Paul Noe |
Paul Noe
paul@thenoes.com |
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 21 August 2003 : 11:04:24
|
You can't actually verify whether a session has timed out or not like that, the only ASP command available for trying to determine whether the client is still active is the Response.IsClientConnected command
http://www.sloppycode.net/asp/?m=31 |
Kiwihosting.Net - The Forum Hosting Specialists
|
 |
|
|
paulnoe
Starting Member
USA
48 Posts |
Posted - 21 August 2003 : 11:05:39
|
| Thanks Gremlin! I knew there was something I was missing. |
Paul Noe
paul@thenoes.com |
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 21 August 2003 : 11:28:48
|
| Your welcome, I've never used that command myself personally so I'm not sure if theres any "tricks" to using it or not. |
Kiwihosting.Net - The Forum Hosting Specialists
|
|
|
|
hnadude
Starting Member
8 Posts |
Posted - 21 August 2003 : 18:12:28
|
for what it's worth...
In the past, I've just checked for stuff like this...
if Session.UserID > ""
dude you're fine
else
dude your dead (or never born) man you got to login first
end if
|
|
|
|
hnadude
Starting Member
8 Posts |
Posted - 21 August 2003 : 18:14:21
|
oops - I meaned
Session.("UserID") |
|
|
|
Gremlin
General Help Moderator
New Zealand
7528 Posts |
Posted - 21 August 2003 : 20:51:08
|
| That would only work if you've actually placed something into that variable at the start of the session though hnadude. |
Kiwihosting.Net - The Forum Hosting Specialists
|
|
|
|
hnadude
Starting Member
8 Posts |
Posted - 22 August 2003 : 12:46:42
|
(My original note was an (fyi type) example, just adding my 1.999 cents)
Yes I agree completely Gremlin, “Response.IsClientConnected” is a clear cut answer , but there’s a couple things to note.
1)
You see, if I was to use “isclientconnected” in my apps it would be an extra un-needed If, if (true).
If (true) I would still need to check contents of the session vars, so I just cut to the chase.
Typically you use sessions vars to hold stuff, important stuff.
And if that stuff ain’t there you would likely need to do something about it, and that something (in all my cases) is the same something I would need to do if the session expired.
Unless you’re only interested in if somebody’s session expired.
(how j’a like my tech jargin)
AND #2)
(this is the biggie) – remembering back a ways, I had some problems with it (isClientConnected).
I’ll quote something here:
(QUOTE)
” The IsClientConnected property determines if the client has disconnected from the server since the last Response.Write. This property is particularly useful since it will prevent the server from continuing to attempt to pass information after an unexpected disconnect.
In ASP 2.0, you must first attempt to pass information to the client in order to use this property. However, in ASP 3.0 you can check the response of using this property before passing any content to the client. (Thus, a simple test will prevent the server from performing unnecessary work.) “
“… In ASP 2.0, you must first send data to the client before being allowed to use this property. It is not the case in ASP 3.0….”
(END QUOTE)
Meaning, you must do at least
<% response.write(“<html>”)%>
before you do the
<% if Response.IsClientConnected then … %>
If I remember correctly, I didn’t want to send –anything- back before I was had the page completly figured out.
I’m (still) using asp 2.0 – and I Believe I ran into this problem of needing to know what’s going on even before sending anything back to the client- so I found it to be an unreliable method – In my situation.
I needed to do direct db calls based on the request, I didn’t want to have to send anything back to the client in order to reliably know if my “state” was good before making the DB calls.
So I decided to take it from the horses mouth, the session vars themselves.
I guess the best use of Response.IsClientConnected, but I’ve not tried this myself, is if your are generating a huge output from, say a db call, you could periodically check if the client still listening – if not then bail.
I should stop talking now.
Gremlin, maybe I just thought this question needed a bit more attention based on my (bad) experience. ;)
|
|
|
| |
Topic |
|
Topic Locked
