I don’t allow users to concurrent login (with same username or different username) to my site. To do that, I used a flag in the db to check the user had login or not and also used !empty($_SESSION[“User”]) to check. If session is not empty, I will then prompt the user “duplicate session found”.
It works fine for IE 8 (open tab or new window) but I can’t seems to get it work with IE 6 and IE 7 (new window). I login with user a with IE 6/7, then open a new window and tries to login with user b, it allows me to login becos the session is empty. If I do the same thing on IE 8, it will disallow me to login cos the session is not empty.
Since all modern browsers (including IE8) have a “private browsing” mode, they can start new browser windows with a fresh session as many times as they want with a single browser too. This isn’t real security, you’re only going to stop computer novices.
Preventing concurrent login sessions for a single account is easy, because you control access to the account.
Preventing a single user from logging into multiple accounts is not easy, because you don’t have a way to identify who is the same user. ip address may seem to work at first, but it will fail when more than one user behind the same router tries to use your site. For example, schools/businesses etc…
You could make a reasonable effort to identify a single computer. But you would probably need to use something like java that can write to thier filesystem(and it will prompt for permission).
Flash can store data clientside, that would probably be shared between browser windows/instances, but “private mode” probably blocks that. I’m not sure.
All of this is easily avoided by a computer power user. It isn’t security. Just smoke.
You can pretend you fixed it by looking at IP address and user agent, but that will cause other problems depending on who the end user of this product is. If it includes businesses, this won’t work either, as everyone will have the same IP to the internet and there are only so many distinct user agents in a company where IT controls the software installed on computers.
It doesn’t matter where you store the sessions on the server, the user can wipe out their session (by using a different browser or by using private browsing mode). If the user doesn’t send you their session identifier then you can’t link it to a session on the server, whether you store those sessions in files or in a database.
It is a feature for IE to have separate instances for separate windows.
So, session cookie don’t go to another window and session starts over. The easiest way solve the problem is to have a cookie with some time to live, say 24 min, which will be passed to another IE instance. But this rises security risks slightly.
If you’re trying to prevent someone from logging in twice with the same user/password, then that should be no problem. Depending on your script, you can check against a table of “active” users, and deny access if they’re already logged in.
If you’re trying to prevent a user from logging in using different credentials on the same browser/computer/internet connection, then I think you’re more or less out of luck, since any attempts to do so can possibly:
a.) prevent legitimate users sharing a local network from logging in
b.) be largely ineffective, due to the sheer number of “holes” you would have to “plug”
c.) become largely a coding nightmare
what about ctrl-N then? I’ve tried preventing a user from logging in twice with a flag stored in the db. But when the user logged in and then press ctrl-N, user can access the same page without logging in.
They are logged in. As you mentioned, some browsers will start a new session with a new window, others won’t. All you should be concerned with is the session: is it there? or not?
This is probably the easiest way to do this. When someone logs in check if they are “active” by using a datetime stamp or something. At that point you can either return a message and say this user is currently logged in, or you can allow that user to log in, and the other user will be logged out.
You could just cookie them with some sort of token (similiar to how the phpsessionid works) and take that cookie value and check it against the database.
Then when another user logs in with the same creds that token will change for the new user, and the other users session will be dead OR if you deny that user to login, the originally logged in user will remain logged in.
I also agree with the quoted poster that trying to attempt different log in credentials from logging in on the same computer (using different browser sessions) is a time sink. You should just explain to the client that it will be expensive and even then it would not be a very user friendly experience, and may cause issues on shared network connections, and other configurations that you may not have the resources to test on.
If your users are able to gain access without logging in simply by opening a new window to the site, then there’s a flaw in the logic that controls access. Without seeing how user authentication is handled, I’m at a loss as to how best to correct the problem. However, you might wish to think about storing your sessions within the database, instead of the usual method of storing them in files. There are several online resources that explain this, including this article by Chris Shiflett.
And, of course, you can find more useful material here.
