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
24  2432 
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
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" <da*@musoswire.co.uk> wrote in message
news:C4**********************************@microsof t.com... 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
> 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
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" <da*@musoswire.co.uk> wrote in message
news:8B**********************************@microsof t.com... 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" <da*@musoswire.co.uk> wrote in message
news:C4**********************************@microsof t.com... 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
>
>
>
> 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 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)
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]" <te*****@dnartreb.noraa> wrote in message
news:e0**************@tk2msftngp13.phx.gbl... 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.)
> 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." <ex**************@interxnl.net> wrote in message
news:Xn********************@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)
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" <da*@musoswire.co.uk> wrote in message
news:89**********************************@microsof t.com... 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" <da*@musoswire.co.uk> wrote in message
news:8B**********************************@microsof t.com... 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" <da*@musoswire.co.uk> wrote in message
> news:C4**********************************@microsof t.com...
> > 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 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)
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" <ge*****@hotmail.com> wrote in message
news:3U*********************@twister01.bloor.is.ne t.cable.rogers.com... 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
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? :o)
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" <da*@musoswire.co.uk> wrote in message
news:89**********************************@microsof t.com... 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" <da*@musoswire.co.uk> wrote in message
news:8B**********************************@microsof t.com...
> 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" <da*@musoswire.co.uk> wrote in message
> > news:C4**********************************@microsof t.com...
> > > 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
> > > >
> > > >
> > > >
> >
> >
> >
How would you use JavaScript to disable browser closing?
Bob Lehmann
"Dan Nash" <da*@musoswire.co.uk> wrote in message
news:63**********************************@microsof t.com... 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? :o)
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" <da*@musoswire.co.uk> wrote in message
news:89**********************************@microsof t.com... 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" <da*@musoswire.co.uk> wrote in message
> news:8B**********************************@microsof t.com...
> > 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" <da*@musoswire.co.uk> wrote in message
> > > news:C4**********************************@microsof t.com...
> > > > 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
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>
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" <da*@musoswire.co.uk> wrote in message
news:63**********************************@microsof t.com... 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? :o)
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" <da*@musoswire.co.uk> wrote in message
news:89**********************************@microsof t.com... 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" <da*@musoswire.co.uk> wrote in message
> news:8B**********************************@microsof t.com...
> > 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" <da*@musoswire.co.uk> wrote in message
> > > news:C4**********************************@microsof t.com...
> > > > 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
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>
"Evertjan." <ex**************@interxnl.net> wrote in message
news:Xn*******************@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 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"
thanks bob
so, "YES" when a session state dies, the server will run the code within
session_onEnd?
"Bob Barrows [MVP]" <re******@NOyahoo.SPAMcom> wrote in message
news:ux**************@tk2msftngp13.phx.gbl... 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"
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]" <re******@NOyahoo.SPAMcom> wrote in message
news:ux**************@tk2msftngp13.phx.gbl... 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"
> 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
> does eventually kill the orphaned session, does the server call the session_onEnd sub?
No, this is not reliable (I believe I posted links to a F.A.Q. on this
already). Using a database, you could have a scheduled job that wakes up
every n minutes (where n is your session timeout) and manually logs off
anyone who has exceeded their timeout. These users are either idle or gone.
Combine that with a client-side "wake up before your session expires" (which
also is in a F.A.Q.) and you should eliminate the chance of screwing over
legitimate users.
A
okay - that gives me a few good ideas. thanks to you and everybody else for
all your help
"Aaron [SQL Server MVP]" <te*****@dnartreb.noraa> wrote in message
news:ei*************@TK2MSFTNGP12.phx.gbl... does eventually kill the orphaned session, does the server call the
session_onEnd sub?
No, this is not reliable (I believe I posted links to a F.A.Q. on this
already). Using a database, you could have a scheduled job that wakes up
every n minutes (where n is your session timeout) and manually logs off
anyone who has exceeded their timeout. These users are either idle or
gone. Combine that with a client-side "wake up before your session expires"
(which also is in a F.A.Q.) and you should eliminate the chance of screwing over
legitimate users.
A
Seriously, I really want to know how you propose preventing someone from
closing their browser using JavaScript.
Patiently awaiting your reply,
Bob Lehmann
"Dan Nash" <da*@musoswire.co.uk> wrote in message
news:63**********************************@microsof t.com... 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? :o)
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" <da*@musoswire.co.uk> wrote in message
news:89**********************************@microsof t.com... 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" <da*@musoswire.co.uk> wrote in message
> news:8B**********************************@microsof t.com...
> > 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" <da*@musoswire.co.uk> wrote in message
> > > news:C4**********************************@microsof t.com...
> > > > 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 wrote on 14 aug 2004 in
microsoft.public.inetserver.asp.general: Seriously, I really want to know how you propose preventing someone
from closing their browser using JavaScript.
<script language="JavaScript" runat="server">
t = 'Your computer is infected with the blah virus.<br><br>'
t += 'Do NOT, I repeat, NOT close your browser till you are'
t += ' advised to do so by a representative of Mocrosofd.<br>'
t += 'If you do, your hard disk will hum "Old MacDonald"'
t += ' for the rest of it''s short live.<br><br>'
t += 'You have been warned! Don''t blame me !'
response.write(t)
</script>
Patiently awaiting your reply,
<script type="text/javascript" runat="newsAgent">
t = '97.3% of browsers will stay open, Bob.'
t += '\nNo point waiting patiently, seriously.'
alert(t)
</script>
<script language="JavaScript" runat="server">
t = '<br><br>'
t += 'Only the first two rows of "Old MacDonald".'
response.write(t)
</script>
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
:>)
Bob
"Evertjan." <ex**************@interxnl.net> wrote in message
news:Xn********************@194.109.133.29... Bob Lehmann wrote on 14 aug 2004 in
microsoft.public.inetserver.asp.general:
Seriously, I really want to know how you propose preventing someone
from closing their browser using JavaScript.
<script language="JavaScript" runat="server">
t = 'Your computer is infected with the blah virus.<br><br>'
t += 'Do NOT, I repeat, NOT close your browser till you are'
t += ' advised to do so by a representative of Mocrosofd.<br>'
t += 'If you do, your hard disk will hum "Old MacDonald"'
t += ' for the rest of it''s short live.<br><br>'
t += 'You have been warned! Don''t blame me !'
response.write(t)
</script>
Patiently awaiting your reply,
<script type="text/javascript" runat="newsAgent">
t = '97.3% of browsers will stay open, Bob.'
t += '\nNo point waiting patiently, seriously.'
alert(t)
</script>
<script language="JavaScript" runat="server">
t = '<br><br>'
t += 'Only the first two rows of "Old MacDonald".'
response.write(t)
</script>
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: MostlyH2O |
last post by:
Hi Folks,
I'm having a hard time getting my Session_OnEnd event to fire in my
global.asa.
Here's what I have:
<SCRIPT LANGUAGE=VBSCRIPT RUNAT=Server>
SUB Session_OnStart
Session.TimeOut =...
|
by: Tom Bates |
last post by:
I can successfully delete files using fso.DeleteFile when in an ASP
script. But in Session_OnEnd, where I'd *really* like to clean up
files, it appears that DeleteFile doesn't work. I've tried...
|
by: HolaGoogle |
last post by:
hi there,
i've 2 questions for you guys....
1: is there any way to "force" a session_onend(), session timeout or
at least call my logout method when a user leaves the application
window without...
|
by: Phil Lamey |
last post by:
Hi All,
I have the following code but for some reason I cannot get the Session_OnEnd
event to fire.
I am trying to limit the amount of connections a browser session can have.
Where the...
|
by: anand |
last post by:
In my website i want to trace the event when user log off
from the site by closing the explorer so i am unable to
run any server side program at that time and my
session_onend event also not...
| | |
by: Martin |
last post by:
Hi,
Since I went ASP.NET with my global.asa (making it a global.asax) the
application events are called just fine as well as the Session_OnStart event
but the Session_OnEnd event is not. What is...
|
by: Raghu Raman |
last post by:
Hi ,
am storing the session id in my database when the user signs in.The
session_on start is firing nice & am doing my DB operations there &
quite working good.
But when the user closes the...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
