I got a user system, with session for both their username and ID. I also got a field in my users table named user_locked which determines if the user's account is locked or not (if it's locked; they can't log in).
Recently I added a feature on my site where it allows me to lock users easily by one click, and I then got the idea: is it possible to force that specific user to get logged out (make his/her session/cookies get destroyed) while leaving everyone elses unharmed?
Is it possible? If it is, how would I do?
Thanks.
My approach would be:
User logs in
You start a session for him and store whatever session variables you want
You store this session's ID in a table at your database with user id/username info
Whenever you want to destroy his session and log him out you follow this routine:
// old_session_id will be retrieved from your database table for
// this current user that you want to force log off
session_id($old_session_id);
session_start();
session_destroy();
Destroy php session remotely
Related
I use php-sessions to check if users are logged in to my app. Is it significantly better for performance than just keeping the user id in a session and checking against the database if the user is logged in instead?
If the password changes or I want to block/log out a user it is easy to just change the database record, but when it lives in a session, can I do that? How?
You can use both.
Use the session variable as a first check, so that you immediately reject any request where the session variable is not set. This saves doing a costly database check for random door-knocking requests.
But if it's set, you still have to do a database check to see if the user's login session is still valid. When a user logs in, create a random token and store it in a session variable and the database. When processing a new request, check if the session variable matches what's in the DB. If an admin wants to force a user to be logged out, they simply invalidate this database record.
I use php-sessions to check if users are logged in to my app
I'm not sure exactly what that looks like - but it sounds horrendous. Either you've broken the session security model or you must be brute-forcing the session data every time you want to find out whom is logged in. Certainly a requirement to maintain a list of active sessions and user identifiers would be best implemented piggy-backed on a custom session handler (for the purposes of triggering - not for a common storage substrate) but you seem to be implying that you you are not doing this.
If the password changes
You cannot keep the password used to authenticate the session in the session.
I am looking at the possibilty to set up a option to keep users logged in. Now I understand a session could be used to allow a user to navigate around without re-entering login information on each page only until the browser is closed and the session is lost. A cookie would be stored client side and has a duration until it expires or the user deletes the cookie.
I was thinking that I could use a combination of both
Create a db table (id,user_id,cookie_token,is_active)
User logs in which creates a row in the db table connecting the user to the cookie_token which is stored on the client browser (system) as well.
Each time a token is created, check to see if the user the token is being created for has any active tokens in the system already and set those to inactive before a new one is created.
Only one token can be active per user
So every time the user visits the site, the system looks up that token and checks is_active fields,
If the user_token is found and is_active = 1 or true, the user data is retrieved (id,name,etc) and this then creates the session and the session variables.
I am not able to find any questions or answers that use a combination of both so it could be that this is just overkill or a very bad idea, I just started to read up on sessions and cookies and have been trying to figure out a system that I could implement myself so would be nice to know if this is good or bad.
I can't reply as a comment anymore, because my reply would be too long...
I've implemented something like follows. Unfortunately I can't remember it precisely, but it would give you a pretty good idea:
Visit before manual login:
Start a session.
At successful login, store a user identification into this session and store a token value into the dB and into the cookie.
Next time the browser visits the page:
(re)Start the session.
Check if a user identification is set in this session.
If so, auto-login the user which matches the identification.
If not (session expired due time restriction or browser close), check if a token value is stored in the cookie and if this value matches a token value stored in the dB.
If an (unexpired) match found, auto-login the user and remove old tokens.
If the user identification is invalid and the token value is invalid/expired:
logout the user (which contains all actions to go back to "public" mode like destroying the session, removing tokens, cookies, etc.).
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 am developing the user management portion of a website that will host a webcast. The goal is to prrevent the same user nam (email address) from being used concurrently. That is, we don't want two individuals using one login to view the event.
I've already setup a table that holds the user registration data with regID as primary key. My thought is to create a login history table with username as primary key, foreign key to user name in registration table. The login history table would simply timestamp when the user logs into the site. However, this won't accomplsih my goal of preventing more than one individual from using the same login name.
Instead, would it be better to have a login status field either in the login history or user table that is set to 1 for logged in and 0 for logged out? It would need a stored procedure to update the value at login and at logout, and would need to be validated when a user logs in such that if login status = 1, user already logged in and cannot login a second time. Is this a feasible approach?
Please share other methods you've used to prevent the same login credential from being shared amongst multiple individuals.
Thanks,
Sid
If it is OK to logout an already logged in user if someone else logs in with the same credentials then you could do the following: when a user logs in generate a random ID in your database for that user and the same in a cookie session. The two must match to authenticate.
Without rolling your own session handler, you could do a little parallel tracking. When a user logs in, you can store the user's session ID and login time in the database (maybe inside the user information table). The login script could then check for the existence if this sessionID and allow/deny login based on the presence of the session ID. If the ID's null/blank, then the user logs in. If there's a session ID present, and it's more than X minutes old, allow the login. Otherwise deny them.
Of course, you'd probably want to roll your own session cleanup handler at that point, so that when stale session files get deleted, you can remove the associated IDs from the database at the same time.
The problem here is detecting the user is logged in (i.e. whether he didn't logout).
One possible way is to register in the database the time of his last activity and the time of his explicit logout. You could then deny a login if it this was attempted less than say 5 minutes ago relatively to his latest activity and if he didn't login in between.
You could force "activity" by having the website pages periodically poll the server with Javascript.
It's easy to determine when someone logs in. It's much harder to determine when someone logs out. If you have a mechanism of killing the webcast streaming to a particular user quickly, you might want to have something which pops up asking the user if they want to kill their other session if you think there might be one active.
How are you doing user sessions on the server? If you store them in the db, you could query the active sessions anytime someone attempts to log in and see if they're already in there. Of course you'd probably also have to check some kind of timestamp since you're not guaranteed that sessions will disappear at session.gc_maxlifetime.
You might want to consider making a global variable in php to store a hash array with login status. This has the benefit that if the application has to be restarted for some reason, the user isn't stuck in the wrong state in the database.
You can store a mapping from user ID to IP or session cookie and redirect requests that come with different information to the login page. If the user logs in, the other session would be invalidated and further requests in the last session forward to the login page.
how do you check if a user already has logged in?
so that if a user in another browser cant log in with the same account.
also, is this a good solution or should i let the user log in in the other browser and then log out the current user and display a message (you are logged in from another location) just like messenger does?
Using sessions is a good way to do this, and is a very common method for controlling authentication.
The flow usually looks something like this:
User visits site, and session_start() is called. A unique session identifier is set for that visitor (ie. a cookie).
User submits his login credentials to a login form
Login credentials are verified, and this fact is stored in the session data with $_SESSION['logged_in'] = true, or something similar
For the rest of the user's time on the site, you can check $_SESSION['logged_in'] to see if the user has logged in.
In order to control a user's logins, you could simply have a field in a database (users table is fine) indicating what the current session id is (retrieved with session_id()) for the user, and if it doesn't match the cookie value you just received, then you immediately call session_destroy() for that id, and consider the user as logged out.
Using $_SESSION means you don't have to worry about generating your own tokens, and gives you the power of the built-in superglobals to facilitate storing information about the user's authentication status.
Personally, I would allow multiple sessions to be active for a user for most web sites, as there's usually not a good reason not to, but it obviously depends on the nature of the site. However, storing the current active session id as mentioned above is a pretty simple way to accomplish this.
Generate a random token upon signing in (or use the sessionid), and store this in the database and in the users cookie. With each page access, ensure that the users token matches the database entry. If the two don't match, alert the user that they've logged in elsewhere.
You could also store the login time, which subsequently would be the time the token was assigned, and require 30 minutes before permitting another user to login with the same ID.
The first half of the question was answered well with how to detect the multiple users but how to treat them I think still needs a bit of work.
First if a user logs in correctly let them in, don't prevent them if they are logged on some other place. If you really don't want the user to have two open sessions then log out the old one or simply update the session id that you are saving so you can bounce out the old connection. You can inform if you want but I would only message the session that you invalidated. If you message the user logging in it becomes annoying when you are only dealing with the case of a user switching computers and they forgot to log out of the old session.
Well All solutions mentioned above will work but if on every page access you are making a call to database and checking for the session token to see weather its the same token assigned to user .. will kill your response time. what i'll suggest is use a caching mechanism instead of database in above said solutions. storing session token into database will add extra field to your database which is actually not required. Use open source caching solution like memcache.
you can make a table like userLoginStatus with fields like clockIn time & clockOut time,
and insert current time in clockIn when user is do login, leave clockOut time blank at that time, it should be updated only when user do clock over logout button,
so you can check specific user's current status, where clockOut is empty that user should be logged in. because it updated only when user do logout.