Hey, I'm trying to get my php website to basically "log out" (session_destroy()) when the same user logs in somewhere else. Is there a way to do this? To remotely destroy a specific session?
Thank guys!
Scott
It's certainly possible, using session_id. When the user logs in somewhere else, you can do this step before starting a new session for the new login:
// The hard part: find out what $old_session_id is
session_id($old_session_id);
session_start();
session_destroy();
// Now proceed to create a new session for the new login
This will destroy the old session on the server side, so when the other computer accesses your application again it will try to access a non-existent session and a new one will be created for it (in which the user is not logged in anymore).
The hard part is finding out what is the ID of the "old" session. There's no one-size-fits-all way of doing that; you need to have some mechanism in place to be able to tell that the session with id XXX belongs to the same user who is logging in now. If you are using database sessions this should be easy enough.
It's not necessary to create your own session handlers.
Simply store the session ID with the username in the database upon login.
Every time the user fetches a page, compare that user's session ID with the stored session ID.
If the session IDs don't match, it means the user has logged in somewhere else, and you should self-destruct.
I can imagine you could do this by using your own session handling. If you store you sessions in database, you could delete them from other app, if you needed to. You would identify the user by user name or something like that.
The best way is to create your own session handlers, if you have full control over how the sessions are stored/retrieved and controlled it's not that difficult to force a log out and it offers you a whole broad range of useful features. If you've got time.
But, for a quicker solution: Store the session ID from PHP in the database with the user, and check this in your isLoggedIn function - or whatever you use. If it doesn't match, force the logout.
Another thing you could do besides Jon's answer (which is great, +1), is initially check where the user came from (referer) and destroy the session if the user comes from another webpage than your own.
$referer = $_SERVER['HTTP_REFERER'];
$referer = parse_url($referer);
if($referer['host'] != "yoursite.com" || $referer['host'] != "www.yoursite.com") {
session_destroy();
}
source
I would like to suggest that what we can do is, get the time and add some addtional value (like manu1234567) and store in database when user log's in .
add that in session also.
now on each page compare both , and if that is equal then proceed , else forward to another page or give some msg .
now other part
when ever another user will login with same username and password, database will update
and for first person there will be error msg "some one logged in from some where else."
Note : time will always different . so there will be very very less chances that two values will be same.
Related
I would like to make my website to allow only one session at a time. For example, let say user has login to my website on firefox, if the user login again to another browser like opera on the same computer or different computer, the session on firefox will be destroyed. However, the session on firefox remained if it remains as one session. May I know how can I do that? I am using php and apache. Thank you.
Regards.
Benjamin
I'll suggest you to do something like this:
Suppose when user "A" loges in to the "Com_1", for the first time. Save a unique code in the database against that session, and same with the user session.
At the mean time if he (user "A") loges in again on "com_2", then check his status in the database and update the unique code in the database.
again back if same user (user "A") refreshes the page on "com_1", we all you need to do is check the unique code from the session and match it to the database, It is for sure it will not match, then log it out and destroy the session.
For keeping the user loggedin, even if browser is closed, you can store the cookie on the browser, and re-generate the session accoordingly.
Hope this helps. Thank you.
You can use the following algorithm
create an integer field in the databse userLoggedInCount
On each login increment that flag and store the result in the session.
On each request check the value in the database and the one in the session, and if the one in the session is less than the one in the DB, invalidate() the session and decrement the value in the database
whenever a session is destroyed decrement the value as well
Credits to Bozho because he posted this, answering to a question
here
Keep a central database table or text file of who is logged in at the moment. If a user is already logged in in another session, invalidate that session by setting the "logged in" flag to false.
I think you'd have to do something like that :
add a "last_session_id" column to your user table
when a user logs in, update its last_session_id field with its current session id
on each page, if the user has an authenticated session, check if the session id is equal to the one recorded in your database. If not, destroy this session.
Store session id in the database. retrieve last login session id from db, set session id using session_id(oldid) and change session variables related to authentication like $_SESSION['LOGIN']
and destroy the session and create new session with new session id. follow example for logic https://www.php.net/manual/en/function.session-create-id.php.
this will make the last login allowed. validate on each page session variables related authentication. this makes it session invalid because of this session_id reset by a new login.
Save users' IP=>SESSION_ID pairs in a database. When user try to load your page you must compare the actual IP=>SESSION_ID pair then allow/deny if the pair is ok/different.
i have a user login system which works off of sessions such that when the user logs in a session variable of user is populated with his/her username, then each page she loads checks this session, if it is not populated then the page is redirected to the login page. apon logout the session is destroyed.
But this still allows a user to open 2 different browsers at the same time and login. I want to stop this, such that if a user logs in and then trys to login using a different browser or pc, they get an error saying the user is already logged in.
So my first thought was to use a data base write, but then how do i know to unset that value if the browser is closed?
all my pages are php, and i use ajax and php scripts to update dynamic content.
So whats the best way to go about this?
they get an error saying the user is already logged in.
That's wrong approach, causing terrible user's experience.
Make it opposite: let that latter in, but make previous one logged out.
You only need to store current session ID in the user's table. If it doesn't match - ask for login.
If you find in DB that user is already logged in simply ask if he/she wants to go on and overwrite old session info. Another way may be adding a time-ticket to your database information (e.g. inserting time) and check how long is elapsed since inserted.
Regards
If I have understood your question properly, I think you can make use of cookie. Once user is logged in, you can create a cookie and set an expiry to browser session time. Before fetching data from DB, you need to check for cookie presence.
I would make another session variable that checks the browser type, if it is different call a view method to output what you said
Initially I came up with the following to see if a user is already logged in:
<?php
session_start();
if(!isset($_SESSION['sessionid'])) {
header("Location: login_form.php");
} else {
echo "You are logged in";
}
?>
$_SESSION['sessionid'] is set when the user manually logs in.
If the user checks "remember me" I set the session cookie's lifetime to be 10 years:
$lifetime = 24*60*60*365*10; // 10 years
setcookie(session_name(),session_id(),time()+ $lifetime,'/');
So now I need to figure out what to do on the server side.... Initially I was thinking of setting session.gc_maxlifetime to a high value so that the server's session data would live for a long time, but 10 years would be ridiculous. Now I'm thinking I should store the session ID in the user table and query that against the session ID. If there's a match, I'll auto log the user in.
My question is:
How do I get the session ID from the client?
My understanding is that it will be available after I call session_start(), but only if the server's session data is still available. If the session has expired (which happens depending on the value of session.gc_maxlifetime) a new session ID will get generated when session_start() is called. This would be problematic as it wouldn't match the last session ID that I stored in the user table.
So the ideas I have to read the session ID, after calling session_start() are:
1) $_SESSION['sessionid']
2) $id = session_id();
3) $_COOKIE["PHPSESSID"];
1 and 2 won't work if the server has destroyed the session data, so I don't think I can use these.
3 might work, but when I tried it (echo $_COOKIE["PHPSESSID"];) I was surprised because the session ID was appeared twice:
the output was this:
htknitopug4b6bv4ql9050pfg6 //htknitopug4b6bv4ql9050pfg6
I simply expected the output to be htknitopug4b6bv4ql9050pfg6.
Can anyone explain the duplicate entry of the session ID? If this behavior is consistent I could always read the first string into my database table.
The short answer is that you shouldn't do that. For reasons why, please see this answer.
As far as what to do instead, I would set a signed cookie (that post shows how) with a large random string unique for each user. Then, when loading the session if it is new, check for the cookie. Then look up the user based on that random string. If you find one, silently log the user back in.
This is a pretty standard remember-me function, but it avoids the pitfals of having long-running sessions, or using the session identifier for other things.
One thing to note, you really should be rotating your session identifier pretty often as well. I typically do it for every login/logout event as well as whenever the user does something sensitive (admin forms, posting content, etc). There's nothing wrong with rotating too much...
I have set up a login system that checks a mysql db validating username,hashed password, and a banned column (0 means not banned and is the default value, 1 means banned). if there banned they obviously cannot loggin.
The problem is i'm new to php and having a hell of a time trying to figure out how to log out a user who is currently logged in. As it stands now my cookie will last for 2weeks, and even if i ban a user, their session will stay active thus they will have acess for 2weeks or less.
How can i force a user to reauthenticate, without penalizing the masses.
Your server knows what cookie is associated with each user. Why not just delete that cookie from its "current sessions" table?
If the cookie is just "username, who is logged in", you have a real problem, because instead of a magic number, the cookie contains real information, and it becomes trivial to forge. Then a malicious user could simply create a cookie saying "I am [admin], and I am logged in", and that's obviously a much larger problem. So if you can't just delete the session cookie from the "known cookies" table to solve this problem, you have a bigger problem to worry about.
If you are doing your authentication system completely on your own (kudos on that, BTW) you merely need to unset the session value that contains their authenticated status. So, if you used:
<?php
session_start();
if(isset($_SESSION['isloggedin']) && isBannedUser())
{
session_unset();
session_destroy();
}
?>
The pseudo-code above calls to a fictitious function called isBannedUser() to determine if they are banned or not. If they are, in my example above I call session_unset() to unset all values stored within the $_SESSION and then session_destroy() to completely close the session. Some would probably argue that you may not need to unset if you're destroying, but I have just gotten into the habit of cleaning up all variables and values that I make in code.
This should be in every page so that you check if they're banned as frequently as possible. With the $_SESSION destroyed the user is, effectively, kicked out of any part of your website that requires authentication. You will need to implement supporting code in your login workflow that keeps a banned user from logging back in.
Hope this is helpful.
If you are storing the session data in a database, delete the row with their session information. Or, delete the file if using files. Then next page load, the login system shouldnt be able to verify their login information (since there's no info for that session), and prompt them to re-login.
On a file-based sessions system, maintain a counter somewhere which triggers a periodic check of the database for updates, something like:
<?php
session_start();
$_SESSION['hits_since_last_verification']++;
if ($_SESSION['hits_since_last_verification'] > 100) {
$banished = ... // get banishment flag from database
if ($banished) {
$_SESSION['loggedIn'] = FALSE;
}
}
?>
and then decide how long you'd like a banned user to be allowed to continue poking around the site until the session data is refreshed and they get booted.
Another option is an external script which runs through the session storage directory, loads each in turn, checks if the user's banned, and updates the session file as appropriate. But this would be painful on even a moderately busy system as you open/unserialize/check banishment/update/reserialize potentially thousands of session files every X minutes.
maybe you want to store the sessions in another table and delete it when you ban the user.
you know. check the table every time the user load a session and if the user isnt there. delete the cookie and destroy the session (sending him to the index of your site)
You can store the userID in the session and on each request, you check if he's banned (SQL query). If true, you destroy his session so he's forced to reauthenticate. Which fails of course because he's banned.
I've scrapped all the tutorials that have never worked for one reason or another, and decided to roll out my own registration/login feature on my own, and to my surprise it actually works!
But what I don't get is how the logic behind keeping somebody logged in works! Like, once they've logged in, do I just $_POST their data to whatever other page they visit and once they're on the new page $_REQUEST that post data from the URL and display a message like: "yeah, you're still logged in"?
I'm a bit confused atm, so I hope this question doesn't confuse you too.
Let us have we have pages like login.php after_login_page1.php after_login_page2.php
You can follow these simple steps
Set $_SESSION['id'] = $userid //userid from db in login.php
always have session_start() in the successive pages like after_login_page1.php, after_login_page2.php
Check if(! isset($_SESSION['id'])){
header("Location: login.php");
}
at the logout.php page give $_SESSION['id']=''; and do a session_destroy()
The easiest imo is to use a session.
Basically this is PHP automatically setting a cookie (or adding a piece to the url, depending your configuration) on the user system and automatically loading it on each pageview. You can then add data to the session and as long as the cookie didn't expire (or was deleted) and/or you don't destroy the session, you will have that data at your disposal on each pageview the user does.
Take a look here for a small intro to sessions: http://www.htmlgoodies.com/beyond/php/article.php/3472581/PHP-Tutorial-Sessions.htm
Once they have logged in you generally have two options. Store their details or an authentication token (something that will help the PHP on the server know who is who) in a session or store it in a cookie. Both have their perks, but you will need to choose the one that works for you.
If you store data in a session, the user cannot access what you have stored, only your code can. This is helpful if you want to store say, their id or username. You can trust that it would always be their id and username, because they cannot modify it.
With cookies, the user can access and modify them because they are stored on their local machines. Because of this, you need to be a bit more sneaky and hash the users details, then verify who it is with some server-side logic. It's a little more complex.
A session implementation might look like this:
session_start(); //Make sure you call this at the top of EVERY page
if($passwordsMatch){
$_SESSION['user'] = $_POST['username'];
}
//Now we have access to $_SESSION['user'] on every page.
On another unrelated page:
session_start();
print "Welcome, ".$_SESSION['user'];
Easiest way is to "keep users logged in" is to use PHP sessions. When you run session_start();, PHP sets cookie with SESSION_ID in users browser so it can identify this user. After that, you can set any data in $_SESSION array which will be saved in session between page requests.