Session_OnEnd doesn't get called when shutting down a browser

N

Nancy Drew

hi all

i'm trying to keep users from being able to login to a site twice at the
same time. everytime a user does a login, i stick their userID into an
application scoped array. if they try to login again, i bounce them to an
error page. i use the session_onEnd sub within global.asa to remove their
userID from the array at the end of their session, and this seems to work
fine. however, if i just shut down the browser, the sub_onEnd doesn't seem
to get called, so i'm unable to remove their userID from the application
array. any ideas on how to force this sub to fire, or is there another way
around this?

tks
 
D

Dan Nash

Hi,

You could try calling a javascript funtion from your <body onunload="">
event to open a new asp page in a window, and use that new asp page to logout
the user?

HTH


Dan
 
N

Nancy Drew

hey dan

excellent idea. one problem may be that the user has a pop-up blocker, or no
client side scripting. i'm hoping for a server side solution if possible?

may still go this route, though.

tks
 
A

Aaron [SQL Server MVP]

excellent idea. one problem may be that the user has a pop-up blocker, or
no
client side scripting. i'm hoping for a server side solution if possible?
Click to expand...

Sorry, but the server can't intercept browser close events, nor can it
detect someone shutting down their system, tripping on the power cord, etc.
Remember how ASP works: a request is made to the server, the ASP code runs
on the server, and returns HTML and client-side code to the client. At this
point, ASP cannot "watch" for events like this, because the ASP code no
longer exists... it was merely a means to an end. This is the stateless
nature of HTTP, and you can only talk to the server side again by
establishing a new connection. And the only way to do that from a closing
window is to use the onunload hack.

http://www.aspfaq.com/2265
http://www.aspfaq.com/2078
http://www.aspfaq.com/2491
 
N

Nancy Drew

yeah - i was thinking about just that - a server side probe. maybe i can
write a cookie to client, request it every 5 minutes or so, and remove the
userID from the application array if i don't get a response...

setting a shorter timeout on the session object won't help - the application
array persists beyond the session object, so the userID is still in there
(meaning the user won't be able to login the next time).
 
A

Aaron [SQL Server MVP]

maybe i can
write a cookie to client, request it every 5 minutes or so
Click to expand...

How are you going to request a cookie from the server every 5 minutes?
Maybe you should reconsider your strategy about preventing two simultaneous
logins. What I would do is prevent two simultaneous logins from the same IP
address. That way, you can store the login information in the database, and
the database can clean up the expired sessions on a schedule. If your
session timeout is reasonable, this should not affect the person who shuts
their browser down at work and logs in when they get home.
 
E

Evertjan.

Nancy Drew wrote on 12 aug 2004 in
microsoft.public.inetserver.asp.general:
yeah - i was thinking about just that - a server side probe. maybe i
can write a cookie to client, request it every 5 minutes or so, and
remove the userID from the application array if i don't get a
response...

setting a shorter timeout on the session object won't help - the
application array persists beyond the session object, so the userID is
still in there (meaning the user won't be able to login the next
time).
Click to expand...

Why cannot we live by the fact that 20 [or whatever] minutes of inactivity
is the session end, unless actively ended (session.end) or sometimes a
server restart.

The energy that goes into this is like the energy put into a [nonexisting,
of cource] ASP wait(). [and even clientside javascript wait()] These are
just remnants of old fashioned linear programming thinking.

Good programming can be achieved with smartly using the possibilities that
ARE available. And lots of leeway to include personal preference and
programming beauty.
 
N

Nancy Drew

what the client really wants to do is keep users from sharing one
membership, so not allowing two different IPs with the same userID to login
is what i'm really trying to do. routinely dumping the login info from a
table doesn't do much to help with a scenario like this.

i think i'm back to using a javascript 'onUnload' event handler to try to
remove the userID from the application array. pop-ups don't seem like a
very good option, and while i've been able to write some hybrid functions to
change a hidden form field to something else, post, and then carry out asp
logic by using fetching the posted value, i don't think that will work in
this case since the form has to post to a page that will be destroyed a
moment later (sorry for run-on sentence). has anybody found a way to call
asp code directly from javascript or know of another good hack for this sort
of thing?
 
N

Nancy Drew

Why cannot we live by the fact that 20 [or whatever] minutes of inactivity
is the session end, unless actively ended (session.end) or sometimes a
server restart.
Click to expand...

i'm not too sure just what you're proposing here. again, the core logic of a
system i'm trying to write says the following:
(a) user attempts to login
(b) check the application array (i.e. arrActiveUsers) for an index with the
same userID as the one the user is trying to use
(c) if we find the userID in the array, bounce the user with an error
message
(d) if we do not find the user, add their info to the application array and
allow them access to the site

all of the above is easy to set up. it's what we do about when the user just
closes the browser, bypassing any logic that could be used to remove them
from the application array. next time they try to login, condition C gets
met because we never removed them from the applicaion array.

i don't see how this is linear thinking and if you have a more elegant
solutin then i'm all ears...


Evertjan. said:
Nancy Drew wrote on 12 aug 2004 in
microsoft.public.inetserver.asp.general:
yeah - i was thinking about just that - a server side probe. maybe i
can write a cookie to client, request it every 5 minutes or so, and
remove the userID from the application array if i don't get a
response...

setting a shorter timeout on the session object won't help - the
application array persists beyond the session object, so the userID is
still in there (meaning the user won't be able to login the next
time).
Click to expand...

Why cannot we live by the fact that 20 [or whatever] minutes of inactivity
is the session end, unless actively ended (session.end) or sometimes a
server restart.

The energy that goes into this is like the energy put into a [nonexisting,
of cource] ASP wait(). [and even clientside javascript wait()] These are
just remnants of old fashioned linear programming thinking.

Good programming can be achieved with smartly using the possibilities that
ARE available. And lots of leeway to include personal preference and
programming beauty.
Click to expand...
 
N

Nancy Drew

i think what aaron was getting at was the stateless nature of http. the
client attemts to login, i write a special cookie to their browser, giving
the cookie a unique name and packing it into the application array. then in
5 minutes, i want to check if the client is still active, so i request that
specially named cookie. sounds great, until you account for the nature of
http. the client opens a socket to a server, doing a request or post, the
server attempts to find the resource the client is after, sends the
appropriate response back to the client, and closes the socket again. a
cookie can only be fetched when the client makes a request - i can't tell
the server to go out and establish a new connection to the client.

i guess i should have known better, but i've been on this and a few other
problems for a few too many hours now and am getting a little dingy.
 
E

Evertjan.

Nancy Drew wrote on 12 aug 2004 in
microsoft.public.inetserver.asp.general:
i'm not too sure just what you're proposing here. again, the core
logic of a system i'm trying to write says the following:
(a) user attempts to login
(b) check the application array (i.e. arrActiveUsers) for an index
with the same userID as the one the user is trying to use
(c) if we find the userID in the array, bounce the user with an error
message
(d) if we do not find the user, add their info to the application
array and allow them access to the site

all of the above is easy to set up. it's what we do about when the
user just closes the browser, bypassing any logic that could be used
to remove them from the application array. next time they try to
login, condition C gets met because we never removed them from the
applicaion array.

i don't see how this is linear thinking and if you have a more elegant
solutin then i'm all ears...
Click to expand...

No, no, not linear thinking,
but linear programming in the case of a wait() example.

===========

Your problem seems to be that a user can lose his/her session without the
server knowing about that and so long as the session is not timed out the
logon is active, and you not wanting to allow more than one login per
user. Correct?

A simple solution could be that, if the user logs in a second time, the
user gets a message:

"You are still logged in in another session. Two simultaneous logins are
not allowed. Can I (I robot/computer) close the other session or do you
want to leave this login?'

However, and that is what I tried to show, with some cunning programming
an incidental double login cannot be all that bad and should be allowed.
Usually the old login is inactive anyway. And what if sometimes man and
wife both use the same user name at exactly the same time? Should be
acceptable.
 
O

only_me

why don't you just remove their UserID from this array after the session
timeout has expired ( virtually)

i.e
User logins in, record userID

Now on every page call a sub that records the current time against that
userID as "time last served" for that user

Now whenever any user tries to log in run a routine that checks all those
"time last served"s - if it is greater than Now + session.timeout + a bit
then that user can be expunged from the array

or have I misunderstood something
 
D

Dan Nash

Hi again,

Just a couple of thoughts...

As you are developing a membership based system, have you thought about
using JS to disable browser closing, and actually forcing them to Logout
using a link on your page?

Also, as Aaron has been saying, the session will time out anyway after 20
minutes. Presumably, to prevent people sharing memberships, when someone logs
in you could presumably delete their current (login) - so the new instance of
login is active, and the old one is inactive, locking out anyone else?

Hope that makes sense? :eek:)

Cheers


Dan
 
N

Nancy Drew

just a point of clarification - sessions will die sooner or later, but if
the user just kills their browser, the session state is still preserved on
the server side, yes? this session state will eventually die since the
client fails to make additional requests to the server. when the server
does eventually kill the orphaned session, does the server call the
session_onEnd sub? if so, then my logic within the session_onEnd sub removes
the user from the application array one way or another and i have no real
problem. are these assumptions correct?
 
N

Nancy Drew

Evertjan. said:
Nancy Drew wrote on 12 aug 2004 in
microsoft.public.inetserver.asp.general:


No, no, not linear thinking,
but linear programming in the case of a wait() example.

===========

Your problem seems to be that a user can lose his/her session without the
server knowing about that and so long as the session is not timed out the
logon is active, and you not wanting to allow more than one login per
user. Correct?
Click to expand...

sort of...

what my client wants is to keep users from sharing access to the site. he
wants to keep two users from being able to login at the same time, using the
same userID. i have two ways to keep track of who is logged in: database or
application scoped variables. i choose the latter since it's less overhead.
so the user logs in, i check the application array to see if the same userID
is in the array, and bounce them to an error page if i find it. failing
that, i add them to the array and let them proceed. the issue i've had is
making sure i remove them from the application array at the end of their
session. applicaiton scoped variables do not die until the server itself is
rebooted or a change is made to global.asa. making sure a process to remove
them from the application array when they just shut down the browser is my
problem...
 
B

Bob Barrows [MVP]

Nancy said:
just a point of clarification - sessions will die sooner or later,
but if the user just kills their browser, the session state is still
preserved on the server side, yes? this session state will
eventually die since the client fails to make additional requests to
the server. when the server does eventually kill the orphaned
session, does the server call the session_onEnd sub? if so, then my
logic within the session_onEnd sub removes the user from the
application array one way or another and i have no real problem. are
these assumptions correct?
Click to expand...

Yes. A Session will end under two circumstances:
1. A Session.Terminate statement is executed in an asp page
2. No requests for new pages for the session id are made before the timeout
period expires

Bob Barrows
 
N

Nancy Drew

thanks bob

so, "YES" when a session state dies, the server will run the code within
session_onEnd?
 
A

Aaron [SQL Server MVP]

sort of...
what my client wants is to keep users from sharing access to the site. he
wants to keep two users from being able to login at the same time, using the
same userID. i have two ways to keep track of who is logged in: database or
application scoped variables. i choose the latter since it's less
Click to expand...
overhead.

I think there is a long-standing perception that database access is a boar.
On the hardware we're running these days, and I made the same argument in a
different thread the other day, I don't think it's as much overhead as you
think. You should test this scenario instead of assuming...
rebooted or a change is made to global.asa. making sure a process to remove
them from the application array when they just shut down the browser is my
problem...
Click to expand...

You're going to have to live with a process that removes them from the
application array or the database after the session would have timed out.
Sorry, there is no magic here. If they shut down their browser, then ,
maybe they'll learn to use the logout feature next time.

Another suggestion here was that the second login could choose to cancel
logging in or kill the existing session. If it's the same user, no harm no
foul, it it's because they are sharing, then mission accomplished.

A
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Global.asa Session_OnEnd 3
Session End doesn't get called 2
ScriptManager OnNavigate doesn't always get fired 2
_matherr doesn't get invoked when sscanf is called. 2
Module missing when embedding? 0
ending sessions when browser is closed 2
Drop Down Menu 2
Yet another appeal for browser sniffing 6

Members online

Total: 18 (members: 1, guests: 17)
Robots: 379

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,020
Latest member
GenesisGai

Latest Threads

Top