Session_OnEnd doesn't get called when shutting down a browser

Discussion in 'ASP General' started by Nancy Drew, Aug 12, 2004.

  1. Nancy Drew

    Nancy Drew Guest

    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
    Nancy Drew, Aug 12, 2004
    #1
    1. Advertising

  2. Nancy Drew

    Dan Nash Guest

    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

    "Nancy Drew" wrote:

    > 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
    >
    >
    >
    Dan Nash, Aug 12, 2004
    #2
    1. Advertising

  3. Nancy Drew

    Nancy Drew Guest

    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


    "Dan Nash" <> wrote in message
    news:...
    > 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
    >
    > "Nancy Drew" wrote:
    >
    > > 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
    > >
    > >
    > >
    Nancy Drew, Aug 12, 2004
    #3
  4. > 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?


    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
    Aaron [SQL Server MVP], Aug 12, 2004
    #4
  5. Nancy Drew

    Nancy Drew Guest

    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).



    "Dan Nash" <> wrote in message
    news:...
    > hey
    >
    > yeah the popup blockers would be a problem. when i used this it was on an
    > internal intranet, so that wasnt an issue.
    >
    > server-side. there must be a way of "probing" the session, say every 5
    > minutes, if u get a response, leave them alone, if u dont, log them out.

    not
    > sure how you would do that. the session will end on timeout anyway -

    perhaps
    > just give your sessions a really samll timeout value in global.asa?
    >
    > HTH
    >
    >
    > Dan
    >
    >
    > "Nancy Drew" wrote:
    >
    > > 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
    > >
    > >
    > > "Dan Nash" <> wrote in message
    > > news:...
    > > > 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
    > > >
    > > > "Nancy Drew" wrote:
    > > >
    > > > > 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
    > > > >
    > > > >
    > > > >

    > >
    > >
    > >
    Nancy Drew, Aug 12, 2004
    #5
  6. > maybe i can
    > write a cookie to client, request it every 5 minutes or so


    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.

    --
    http://www.aspfaq.com/
    (Reverse address to reply.)
    Aaron [SQL Server MVP], Aug 12, 2004
    #6
  7. Nancy Drew

    Evertjan. Guest

    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).


    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.

    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
    Evertjan., Aug 12, 2004
    #7
  8. Nancy Drew

    Nancy Drew Guest

    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?


    "Aaron [SQL Server MVP]" <> wrote in message
    news:...
    > > maybe i can
    > > write a cookie to client, request it every 5 minutes or so

    >
    > 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.
    >
    > --
    > http://www.aspfaq.com/
    > (Reverse address to reply.)
    >
    >
    Nancy Drew, Aug 12, 2004
    #8
  9. Nancy Drew

    Nancy Drew Guest

    > 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.


    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." <> wrote in message
    news:Xns9543DEACFB034eejj99@194.109.133.29...
    > 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).

    >
    > 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.
    >
    > --
    > Evertjan.
    > The Netherlands.
    > (Please change the x'es to dots in my emailaddress)
    Nancy Drew, Aug 12, 2004
    #9
  10. Nancy Drew

    Nancy Drew Guest

    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.

    "Dan Nash" <> wrote in message
    news:...
    > hiya
    >
    > could you not do the probing, and then update the application array
    > accordingly?
    >
    > Aaron's Ip solution might be the way to go though.
    >
    > "Nancy Drew" wrote:
    >
    > > 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).
    > >
    > >
    > >
    > > "Dan Nash" <> wrote in message
    > > news:...
    > > > hey
    > > >
    > > > yeah the popup blockers would be a problem. when i used this it was on

    an
    > > > internal intranet, so that wasnt an issue.
    > > >
    > > > server-side. there must be a way of "probing" the session, say every 5
    > > > minutes, if u get a response, leave them alone, if u dont, log them

    out.
    > > not
    > > > sure how you would do that. the session will end on timeout anyway -

    > > perhaps
    > > > just give your sessions a really samll timeout value in global.asa?
    > > >
    > > > HTH
    > > >
    > > >
    > > > Dan
    > > >
    > > >
    > > > "Nancy Drew" wrote:
    > > >
    > > > > 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
    > > > >
    > > > >
    > > > > "Dan Nash" <> wrote in message
    > > > > news:...
    > > > > > 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
    > > > > >
    > > > > > "Nancy Drew" wrote:
    > > > > >
    > > > > > > 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
    > > > > > >
    > > > > > >
    > > > > > >
    > > > >
    > > > >
    > > > >

    > >
    > >
    > >
    Nancy Drew, Aug 12, 2004
    #10
  11. Nancy Drew

    Evertjan. Guest

    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...


    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.


    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
    Evertjan., Aug 12, 2004
    #11
  12. Nancy Drew

    only_me Guest

    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



    "Nancy Drew" <> wrote in message
    news:3UNSc.1660271$...
    > 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
    >
    >
    only_me, Aug 13, 2004
    #12
  13. Nancy Drew

    Dan Nash Guest

    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

    "Nancy Drew" wrote:

    > 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.
    >
    > "Dan Nash" <> wrote in message
    > news:...
    > > hiya
    > >
    > > could you not do the probing, and then update the application array
    > > accordingly?
    > >
    > > Aaron's Ip solution might be the way to go though.
    > >
    > > "Nancy Drew" wrote:
    > >
    > > > 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).
    > > >
    > > >
    > > >
    > > > "Dan Nash" <> wrote in message
    > > > news:...
    > > > > hey
    > > > >
    > > > > yeah the popup blockers would be a problem. when i used this it was on

    > an
    > > > > internal intranet, so that wasnt an issue.
    > > > >
    > > > > server-side. there must be a way of "probing" the session, say every 5
    > > > > minutes, if u get a response, leave them alone, if u dont, log them

    > out.
    > > > not
    > > > > sure how you would do that. the session will end on timeout anyway -
    > > > perhaps
    > > > > just give your sessions a really samll timeout value in global.asa?
    > > > >
    > > > > HTH
    > > > >
    > > > >
    > > > > Dan
    > > > >
    > > > >
    > > > > "Nancy Drew" wrote:
    > > > >
    > > > > > 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
    > > > > >
    > > > > >
    > > > > > "Dan Nash" <> wrote in message
    > > > > > news:...
    > > > > > > 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
    > > > > > >
    > > > > > > "Nancy Drew" wrote:
    > > > > > >
    > > > > > > > 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
    > > > > > > >
    > > > > > > >
    > > > > > > >
    > > > > >
    > > > > >
    > > > > >
    > > >
    > > >
    > > >

    >
    >
    >
    Dan Nash, Aug 13, 2004
    #13
  14. Nancy Drew

    Bob Lehmann Guest

    How would you use JavaScript to disable browser closing?

    Bob Lehmann

    "Dan Nash" <> wrote in message
    news:...
    > 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
    >
    > "Nancy Drew" wrote:
    >
    > > 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.
    > >
    > > "Dan Nash" <> wrote in message
    > > news:...
    > > > hiya
    > > >
    > > > could you not do the probing, and then update the application array
    > > > accordingly?
    > > >
    > > > Aaron's Ip solution might be the way to go though.
    > > >
    > > > "Nancy Drew" wrote:
    > > >
    > > > > 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).
    > > > >
    > > > >
    > > > >
    > > > > "Dan Nash" <> wrote in message
    > > > > news:...
    > > > > > hey
    > > > > >
    > > > > > yeah the popup blockers would be a problem. when i used this it

    was on
    > > an
    > > > > > internal intranet, so that wasnt an issue.
    > > > > >
    > > > > > server-side. there must be a way of "probing" the session, say

    every 5
    > > > > > minutes, if u get a response, leave them alone, if u dont, log

    them
    > > out.
    > > > > not
    > > > > > sure how you would do that. the session will end on timeout

    anyway -
    > > > > perhaps
    > > > > > just give your sessions a really samll timeout value in

    global.asa?
    > > > > >
    > > > > > HTH
    > > > > >
    > > > > >
    > > > > > Dan
    > > > > >
    > > > > >
    > > > > > "Nancy Drew" wrote:
    > > > > >
    > > > > > > 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
    > > > > > >
    > > > > > >
    > > > > > > "Dan Nash" <> wrote in message
    > > > > > > news:...
    > > > > > > > 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
    > > > > > > >
    > > > > > > > "Nancy Drew" wrote:
    > > > > > > >
    > > > > > > > > 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
    > > > > > > > >
    > > > > > > > >
    > > > > > > > >
    > > > > > >
    > > > > > >
    > > > > > >
    > > > >
    > > > >
    > > > >

    > >
    > >
    > >
    Bob Lehmann, Aug 13, 2004
    #14
  15. Nancy Drew

    Nancy Drew Guest

    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?


    "Dan Nash" <> wrote in message
    news:...
    > 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
    >
    > "Nancy Drew" wrote:
    >
    > > 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.
    > >
    > > "Dan Nash" <> wrote in message
    > > news:...
    > > > hiya
    > > >
    > > > could you not do the probing, and then update the application array
    > > > accordingly?
    > > >
    > > > Aaron's Ip solution might be the way to go though.
    > > >
    > > > "Nancy Drew" wrote:
    > > >
    > > > > 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).
    > > > >
    > > > >
    > > > >
    > > > > "Dan Nash" <> wrote in message
    > > > > news:...
    > > > > > hey
    > > > > >
    > > > > > yeah the popup blockers would be a problem. when i used this it

    was on
    > > an
    > > > > > internal intranet, so that wasnt an issue.
    > > > > >
    > > > > > server-side. there must be a way of "probing" the session, say

    every 5
    > > > > > minutes, if u get a response, leave them alone, if u dont, log

    them
    > > out.
    > > > > not
    > > > > > sure how you would do that. the session will end on timeout

    anyway -
    > > > > perhaps
    > > > > > just give your sessions a really samll timeout value in

    global.asa?
    > > > > >
    > > > > > HTH
    > > > > >
    > > > > >
    > > > > > Dan
    > > > > >
    > > > > >
    > > > > > "Nancy Drew" wrote:
    > > > > >
    > > > > > > 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
    > > > > > >
    > > > > > >
    > > > > > > "Dan Nash" <> wrote in message
    > > > > > > news:...
    > > > > > > > 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
    > > > > > > >
    > > > > > > > "Nancy Drew" wrote:
    > > > > > > >
    > > > > > > > > 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
    > > > > > > > >
    > > > > > > > >
    > > > > > > > >
    > > > > > >
    > > > > > >
    > > > > > >
    > > > >
    > > > >
    > > > >

    > >
    > >
    > >
    Nancy Drew, Aug 13, 2004
    #15
  16. Nancy Drew

    Nancy Drew Guest

    "Evertjan." <> wrote in message
    news:Xns954433A1173Ceejj99@194.109.133.29...
    > 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...

    >
    > 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?


    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...

    >
    > 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.
    >
    >
    > --
    > Evertjan.
    > The Netherlands.
    > (Please change the x'es to dots in my emailaddress)
    Nancy Drew, Aug 13, 2004
    #16
  17. Nancy Drew wrote:
    > 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?
    >


    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
    --
    Microsoft MVP - ASP/ASP.NET
    Please reply to the newsgroup. This email account is my spam trap so I
    don't check it very often. If you must reply off-line, then remove the
    "NO SPAM"
    Bob Barrows [MVP], Aug 13, 2004
    #17
  18. Nancy Drew

    Nancy Drew Guest

    thanks bob

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


    "Bob Barrows [MVP]" <> wrote in message
    news:...
    > Nancy Drew wrote:
    > > 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?
    > >

    >
    > 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
    > --
    > Microsoft MVP - ASP/ASP.NET
    > Please reply to the newsgroup. This email account is my spam trap so I
    > don't check it very often. If you must reply off-line, then remove the
    > "NO SPAM"
    >
    >
    Nancy Drew, Aug 13, 2004
    #18
  19. It is supposed to. However:
    http://www.aspfaq.com/show.asp?id=2078

    Bob Barrows

    Nancy Drew wrote:
    > thanks bob
    >
    > so, "YES" when a session state dies, the server will run the code
    > within session_onEnd?
    >
    >
    > "Bob Barrows [MVP]" <> wrote in message
    > news:...
    >> Nancy Drew wrote:
    >>> 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?
    >>>

    >>
    >> 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
    >> --
    >> Microsoft MVP - ASP/ASP.NET
    >> Please reply to the newsgroup. This email account is my spam trap so
    >> I don't check it very often. If you must reply off-line, then remove
    >> the "NO SPAM"


    --
    Microsoft MVP - ASP/ASP.NET
    Please reply to the newsgroup. This email account is my spam trap so I
    don't check it very often. If you must reply off-line, then remove the
    "NO SPAM"
    Bob Barrows [MVP], Aug 13, 2004
    #19
  20. > 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.

    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...


    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
    Aaron [SQL Server MVP], Aug 13, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?Qm9zc29tYQ==?=

    Windows 98 SE freezes when shutting down.

    =?Utf-8?B?Qm9zc29tYQ==?=, Jun 26, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    569
    Eddie
    Jun 27, 2005
  2. Martin

    Session_OnEnd is not being called

    Martin, Dec 29, 2003, in forum: ASP .Net
    Replies:
    6
    Views:
    3,458
    Alvin Bruney
    Dec 30, 2003
  3. rooster575
    Replies:
    1
    Views:
    358
    Lau Lei Cheong
    Jul 2, 2004
  4. J-T
    Replies:
    4
    Views:
    9,276
  5. Jack
    Replies:
    2
    Views:
    1,554
Loading...

Share This Page