By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,512 Members | 3,689 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,512 IT Pros & Developers. It's quick & easy.

Need to find-out improper sign-out

P: n/a
Is there any way to run a function or a code-block whenever the client-
server communication breaks off. (ie power-off, browser-crash...)

Why I need this is, I want to update a login-table to trace user's
leave the portal without proper log-off or sign-out.

Every time a user at proper sign-in, a flag is set & account is locked
until he sign-out by updating in the login-table.At sign-out the flag
is released & his account is ready to log-in again.
Is my logic right?

Kesavan.M
m.*******@hotmail.com

Mar 3 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Kesavan wrote:
Is there any way to run a function or a code-block whenever the client-
server communication breaks off. (ie power-off, browser-crash...)

Why I need this is, I want to update a login-table to trace user's
leave the portal without proper log-off or sign-out.

Every time a user at proper sign-in, a flag is set & account is locked
until he sign-out by updating in the login-table.At sign-out the flag
is released & his account is ready to log-in again.
Is my logic right?

Kesavan.M
m.*******@hotmail.com
Sorry, HTTP is a stateless protocol. You can tell when a user accesses
your site, but not when he/she leaves.

Best is to use sessions and have a timeout on the session.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 3 '07 #2

P: n/a
>Is there any way to run a function or a code-block whenever the client-
>server communication breaks off. (ie power-off, browser-crash...)
No. The best you can do is time out a session X time from the last
hit. Another kind of "improper sign-out" you won't see is clicking
on an ad and not coming back, clicking on the HOME button, typing
in a URL, etc. Know also that communication doesn't necessarily
stay up during a session. It may disconnect after completing each
page.
>Why I need this is, I want to update a login-table to trace user's
leave the portal without proper log-off or sign-out.
Find something else to need.
>Every time a user at proper sign-in, a flag is set & account is locked
until he sign-out by updating in the login-table.At sign-out the flag
is released & his account is ready to log-in again.
Is my logic right?
Why on earth would you need such a thing, besides trying to drive off users?

Mar 3 '07 #3

P: n/a
Rik
Gordon Burditt <go***********@burditt.orgwrote:
>Is there any way to run a function or a code-block whenever the client-
server communication breaks off. (ie power-off, browser-crash...)

No. The best you can do is time out a session X time from the last
hit. Another kind of "improper sign-out" you won't see is clicking
on an ad and not coming back, clicking on the HOME button, typing
in a URL, etc. Know also that communication doesn't necessarily
stay up during a session. It may disconnect after completing each
page.
>Why I need this is, I want to update a login-table to trace user's
leave the portal without proper log-off or sign-out.

Find something else to need.
>Every time a user at proper sign-in, a flag is set & account is locked
until he sign-out by updating in the login-table.At sign-out the flag
is released & his account is ready to log-in again.
Is my logic right?

Why on earth would you need such a thing, besides trying to drive off
users?
I'd even go so far as to say: the last one to log in clearly knows the
password, if another one is currently logged in under the same credentials
I log them out instantly. People can get seperate logins a plenty, no
reason to share, and another little security measure to, well, not
prevent, but end a specific session hijack.

--
Rik Wasmus
Mar 3 '07 #4

P: n/a
>>Is there any way to run a function or a code-block whenever the client-
>>server communication breaks off. (ie power-off, browser-crash...)

No. The best you can do is time out a session X time from the last
hit. Another kind of "improper sign-out" you won't see is clicking
on an ad and not coming back, clicking on the HOME button, typing
in a URL, etc. Know also that communication doesn't necessarily
stay up during a session. It may disconnect after completing each
page.
>>Why I need this is, I want to update a login-table to trace user's
leave the portal without proper log-off or sign-out.

Find something else to need.
>>Every time a user at proper sign-in, a flag is set & account is locked
until he sign-out by updating in the login-table.At sign-out the flag
is released & his account is ready to log-in again.
Is my logic right?

Why on earth would you need such a thing, besides trying to drive off
users?

I'd even go so far as to say: the last one to log in clearly knows the
password, if another one is currently logged in under the same credentials
I log them out instantly.
I'll agree here: if you *must* insist on one login at a time, kill
the *old* session (which may have just suffered modem disconnectus),
not the *new* one. It also acts to discourage account sharing
(situation: pay site for pr0n or whatever). If you share your
account widely, *all* people trying to use it are likely to get
booted off often. It's harder to implement, though. One thing
that makes it a bit easier is to use a session save handler which
puts session data in a database, thereby making a search for people
logged in under the same account easier.
>People can get seperate logins a plenty, no
reason to share, and another little security measure to, well, not
prevent, but end a specific session hijack.
Depending on the design of the site, there are plenty of reasons
for the same user to try to pull up two different pages from the
site at the same time (for example, to look at two things you might
want and compare features side-by-side to decide which to buy), and
many times it is necessary made to log in twice to do that.

Mar 4 '07 #5

P: n/a
Rik
Gordon Burditt <go***********@burditt.orgwrote:
>>>Every time a user at proper sign-in, a flag is set & account is locked
until he sign-out by updating in the login-table.At sign-out the flag
is released & his account is ready to log-in again.
Is my logic right?

Why on earth would you need such a thing, besides trying to drive off
users?

I'd even go so far as to say: the last one to log in clearly knows the
password, if another one is currently logged in under the same
credentials
I log them out instantly.

I'll agree here: if you *must* insist on one login at a time, kill
the *old* session (which may have just suffered modem disconnectus),
not the *new* one. It also acts to discourage account sharing
(situation: pay site for pr0n or whatever). If you share your
account widely, *all* people trying to use it are likely to get
booted off often. It's harder to implement, though. One thing
that makes it a bit easier is to use a session save handler which
puts session data in a database, thereby making a search for people
logged in under the same account easier.
I don't go as far as to use a custom save handler most of the time.
Determining wether a user is logged in is done with the help of a database
query though, where session id's and user id's are saved of the current
'active' users, which also gives a nice oppertunity to check the time of
last activity etc.
>People can get seperate logins a plenty, no
reason to share, and another little security measure to, well, not
prevent, but end a specific session hijack.

Depending on the design of the site, there are plenty of reasons
for the same user to try to pull up two different pages from the
site at the same time (for example, to look at two things you might
want and compare features side-by-side to decide which to buy), and
many times it is necessary made to log in twice to do that.
Normally, no. As long as he's using the same browser, he will have the
same session id, and it will still be considered one user serverside, even
if the requests hit the server at exactly the same moment (which 'never'
happens). If you use different browsers (firefox & MSIE for instance),
then they'll get different id's, simply because they don't use each
hothers cookies. On any normal site, opening a wide variety of pages with
a single login is perfectly possible.
--
Rik Wasmus
Mar 4 '07 #6

P: n/a
>>>>Every time a user at proper sign-in, a flag is set & account is locked
>>>>until he sign-out by updating in the login-table.At sign-out the flag
is released & his account is ready to log-in again.
Is my logic right?

Why on earth would you need such a thing, besides trying to drive off
users?

I'd even go so far as to say: the last one to log in clearly knows the
password, if another one is currently logged in under the same
credentials
I log them out instantly.

I'll agree here: if you *must* insist on one login at a time, kill
the *old* session (which may have just suffered modem disconnectus),
not the *new* one. It also acts to discourage account sharing
(situation: pay site for pr0n or whatever). If you share your
account widely, *all* people trying to use it are likely to get
booted off often. It's harder to implement, though. One thing
that makes it a bit easier is to use a session save handler which
puts session data in a database, thereby making a search for people
logged in under the same account easier.

I don't go as far as to use a custom save handler most of the time.
Determining wether a user is logged in is done with the help of a database
query though, where session id's and user id's are saved of the current
'active' users, which also gives a nice oppertunity to check the time of
last activity etc.
Well, I wrote a save handler, and it's turned out to have lots of
uses. Part of the idea is that if you delete the session entry,
the user is logged out as of the next hit. You also get "last hit"
info. And it's useful for debugging. But there are other ways in
the "is he logged in" check to accomplish the same thing.
>>People can get seperate logins a plenty, no
reason to share, and another little security measure to, well, not
prevent, but end a specific session hijack.

Depending on the design of the site, there are plenty of reasons
for the same user to try to pull up two different pages from the
site at the same time (for example, to look at two things you might
want and compare features side-by-side to decide which to buy), and
many times it is necessary made to log in twice to do that.

Normally, no. As long as he's using the same browser, he will have the
same session id, and it will still be considered one user serverside, even
if the requests hit the server at exactly the same moment (which 'never'
happens).
I have been asked quite a few times about problems with this. It
seems some sites use session data for navigation, search parameters,
and options. If you have two browser instances with the same session
ID, they share this data. Browser A searches on "motorcycle".
Browser B searches on "Barbie Dolls". Browser A refines search
with "helmet", and gets back an entry for a Barbie motorcycle outfit
including a helmet, and nothing about a real motorcycle helmet.
These users needed to *FORCE* having two different sessions in order
to do what they wanted to do. I don't remember which sites had this
issue. It wasn't Ebay. But I do recall it being real easy to bid on
or order the wrong thing if you had two browser windows open to
different items.

It seems to me that there was a certain patchlevel of IE6 that made
this worse. Perhaps according to the specs, IE6 was correct, but
it was causing a lot of questions at my ISP.

>If you use different browsers (firefox & MSIE for instance),
then they'll get different id's, simply because they don't use each
hothers cookies. On any normal site, opening a wide variety of pages with
a single login is perfectly possible.

Mar 4 '07 #7

P: n/a
On Mar 4, 5:35 am, gordonb.ku...@burditt.org (Gordon Burditt) wrote:
>>>Every time a user at proper sign-in, a flag is set & account is locked
until he sign-out by updating in the login-table.At sign-out the flag
is released & his account is ready to log-in again.
Is my logic right?
>>Why on earth would you need such a thing, besides trying to drive off
users?
>I'd even go so far as to say: the last one to log in clearly knows the
password, if another one is currently logged in under the same
credentials
I log them out instantly.
I'll agree here: if you *must* insist on one login at a time, kill
the *old* session (which may have just suffered modem disconnectus),
not the *new* one. It also acts to discourage account sharing
(situation: pay site for pr0n or whatever). If you share your
account widely, *all* people trying to use it are likely to get
booted off often. It's harder to implement, though. One thing
that makes it a bit easier is to use a session save handler which
puts session data in a database, thereby making a search for people
logged in under the same account easier.
I don't go as far as to use a custom save handler most of the time.
Determining wether a user is logged in is done with the help of a database
query though, where session id's and user id's are saved of the current
'active' users, which also gives a nice oppertunity to check the time of
last activity etc.

Well, I wrote a save handler, and it's turned out to have lots of
uses. Part of the idea is that if you delete the session entry,
the user is logged out as of the next hit. You also get "last hit"
info. And it's useful for debugging. But there are other ways in
the "is he logged in" check to accomplish the same thing.
>People can get seperate logins a plenty, no
reason to share, and another little security measure to, well, not
prevent, but end a specific session hijack.
Depending on the design of the site, there are plenty of reasons
for the same user to try to pull up two different pages from the
site at the same time (for example, to look at two things you might
want and compare features side-by-side to decide which to buy), and
many times it is necessary made to log in twice to do that.
Normally, no. As long as he's using the same browser, he will have the
same session id, and it will still be considered one user serverside, even
if the requests hit the server at exactly the same moment (which 'never'
happens).

I have been asked quite a few times about problems with this. It
seems some sites use session data for navigation, search parameters,
and options. If you have two browser instances with the same session
ID, they share this data. Browser A searches on "motorcycle".
Browser B searches on "Barbie Dolls". Browser A refines search
with "helmet", and gets back an entry for a Barbie motorcycle outfit
including a helmet, and nothing about a real motorcycle helmet.
These users needed to *FORCE* having two different sessions in order
to do what they wanted to do. I don't remember which sites had this
issue. It wasn't Ebay. But I do recall it being real easy to bid on
or order the wrong thing if you had two browser windows open to
different items.

It seems to me that there was a certain patchlevel of IE6 that made
this worse. Perhaps according to the specs, IE6 was correct, but
it was causing a lot of questions at my ISP.
If you use different browsers (firefox & MSIE for instance),
then they'll get different id's, simply because they don't use each
hothers cookies. On any normal site, opening a wide variety of pages with
a single login is perfectly possible.
Hi all,

it seems the original question has not been answered yet. If yes,
please ignore my mumbling.
Is there any way to run a function or a code-block whenever the client-
server communication breaks off. (ie power-off, browser-crash...)
1) If you write your own session handler you can use the function for
the garbage collection to do this.

2) If you store somewhere (a login log?) if when a user has logged in
and when the user has logged out, you can derive your needed
information from there.

good luck
Martin

------------------------------------------------
online accounting on bash bases
Online Einnahmen-Ausgaben-Rechnung
http://www.ea-geier.at
------------------------------------------------
m2m server software gmbh
http://www.m2m.at


Mar 4 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.