|
|
Posted by Gordon Burditt on 03/04/07 04:35
>>>>> 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.
Navigation:
[Reply to this message]
|