Page 1 of 1

User conflict...

Posted: Wed Mar 21, 2012 1:54 pm
by orbdrums
I have a site that allows members to log in. If a member is logged in and another browser session is started with another member logging in, the second member becomes the active member on the first browser session effectively hijacking the first members account. I'm not sure which code is allowing this to happen. Does anyone have a suggestion?
Thanks.

Re: User conflict...

Posted: Wed Mar 21, 2012 5:13 pm
by social_experiment
orbdrums wrote:another browser session is started
Is this using the same browser (say use FF then still using FF access the page) or a different browser (FF then go to the page using Chrome)? If it's the same browser then it could be because there is already an existing session which you are now accessing.

Re: User conflict...

Posted: Wed Mar 21, 2012 5:51 pm
by califdon
orbdrums wrote:I have a site that allows members to log in. If a member is logged in and another browser session is started with another member logging in, the second member becomes the active member on the first browser session effectively hijacking the first members account. I'm not sure which code is allowing this to happen. Does anyone have a suggestion?
Thanks.
Sounds to me like the only way that can happen is if the second member logs in on the same computer and using the same browser, without closing the browser. Otherwise is obviously won't be the same session. But of course none of our comments make any sense since we haven't seen your code.

Re: User conflict...

Posted: Wed Mar 21, 2012 9:54 pm
by orbdrums
Thanks for the replies and here is more info. I am using Safari and it is the same browser session in a different tab on the same computer. What I'm trying to avoid is a member logging in on one tab and another member logging in another tab on the same computer which causes the conflict. Is there a way to make a user log off before another user logs in on the same computer? That would take care of the issue.

Re: User conflict...

Posted: Thu Mar 22, 2012 2:31 am
by social_experiment
orbdrums wrote:same browser session in a different tab on the same computer
That's still the same session started with the first login
orbdrums wrote: Is there a way to make a user log off before another user logs in on the same computer?
You can unset any set session variables when the login page is accessed; depending how your "auth" script is written it will log out / cancel sessions for any logged in user on that specific computer

Re: User conflict...

Posted: Thu Mar 22, 2012 12:14 pm
by califdon
I think you have a fundamental question to ask yourself: how can you possibly know whether it is the same or a different person who is using the same computer and the same browser, merely opening a new tab? That's exactly the same as the same person just deciding to sign on as a different user.

What you could do, I suppose, is (as part of your login page) check to see if a user is already logged on in the current session, and not allow another login until the currently logged-in user has logged out.

Re: User conflict...

Posted: Thu Mar 22, 2012 10:26 pm
by orbdrums
Here is the auth.php file. I'm not real sure what code (or even the logic) to add to this file.

Code: Select all

<?php
	session_start();
	
	if(!isset($_SESSION['SESS_MEMBER_ID']) || (trim($_SESSION['SESS_MEMBER_ID']) == ''))
        {
		header("location: access-denied.php");
		exit();
	}
?>

Re: User conflict...

Posted: Fri Mar 23, 2012 2:28 am
by social_experiment
If you were to follow my advice you would place the code on your login page;

Code: Select all

<?php
 $_SESSION = array();
 // or 
 unset($_SESSION); 
?>
This unsets (removes) any session variables that exists: this would then log out any person logged in on the same browser.

I don't understand the necessity for this sort of measure; if you could perhaps explain a bit more. Logically speaking two people using the same browser and the same terminal for the same application doesn't make sense, it would be easier to create a general user which grants access to all users (same privileges, same functions). This might be the case but then forcing logout would be pointless as the application doesn't have to logout. For a multi-user setup this is rather pointless imo; if the system has user specific functions & roles (one user is admin while another is a normal user) then common sense dictates that you would logout before allowing someone else, who might be a lower lever user, to work on the computer

Re: User conflict...

Posted: Fri Mar 23, 2012 12:52 pm
by orbdrums
I see your point now. I'm developing in a localhost environment and doing some testing that is probably not a real world situation. And besides, if someone doesn't log out then it makes sense that the new session would take precedent. I'm over thinking this as usual. Thanks for the advice and clarity.

Re: User conflict...

Posted: Fri Mar 23, 2012 1:03 pm
by califdon
orbdrums wrote:Here is the auth.php file. I'm not real sure what code (or even the logic) to add to this file.

Code: Select all

<?php
	session_start();
	
	if(!isset($_SESSION['SESS_MEMBER_ID']) || (trim($_SESSION['SESS_MEMBER_ID']) == ''))
        {
		header("location: access-denied.php");
		exit();
	}
?>
If you will read my previous post again, you'll see that I suggested that you add some code to your login page. What you show above has nothing that would log-in a user, it only redirects to another page if a user is not already logged in. What I was suggesting was that, when your code is in the process of logging in a user, it could check to make sure that the current session doesn't already have a user logged in, and if it does, you could take some kind of action such as informing the user that he/she is already logged in, or aborting the login, or whatever you may want to do. That's the logic.

However, along with social_experiment, I find that your basic premise seems unusual. Do you expect that several people may be in the same room, using the same computer, using the same open browser? Unless that's a part of your expected usage, I don't see that you should even be considering this odd situation. If this is, in fact, an expected circumstance, it is highly unusual and I can't immediately think of a rational way to handle it.