Currently, I have it set up such that, when a user logs into their account, it checks the cookies table in the database. If a row already exists in the database for that user, it updates the database and the user's cookie with a new hash. If a row doesn't exist for that user, it sets a new hash in the database as well as sets the cookie for the user.
The issue with this is that, if the user logs in from a different device, it will log them out on any other devices as the hash in the cookies won't match for the other devices.
How can I solve this issue? Would it be better to just, rather than update the hash in the database, keep adding new rows for each time they log in?
Please help.
if user already exists in database - do not update hash, just use hash from db to set cookie for new user
I'd add new rows for each time they login. Record the timestamp of when they logged in then you can check and remove any expired cookies so you don't have a ton of rows with expired cookie information hanging around. I'd perform this check every time the user logs in.
You also might want to consider storing the IP and/or user agent. Then you could setup a page to display to the user their current sessions and give them the option to revoke them if they want.
Related
I know this is a recursive question, but, I haven't found a new solution, or a solution based on the new frontend frameworks or technologies.
I've a Vue + PHP application that users can olny log once per time. My current solution to block concurrent access is making a call to a PHP page with Ajax from 5 to 5 minutes storing the time. I store a flag in DB too, whether it has been registered or not. So, when the user try to log in, I check if the time is greater than 6 minutes or the flag is set to 0.
I think this is not the best way to do this. When the application has too many users it can cause too much load on the server.
There is a way to do like Netflix? An warn when triyng to connect and was logged in another machine.
If your end goal is to have it so that any given account can only be logged into one machine at a time, generate a unique ID at login and write that ID to the database for that user. Set that ID as a cookie for the user. When you receive traffic from that user, only consider them logged in if their cookie matches the value in the database.
When the user logs in to a new device, a new unique ID is generated and sent as a cookie to that new device. The new device's traffic has a cookie that matches the database, and is therefore considered logged in. When the old device visits your application, the login cookie no longer matches the value in the database, so that user is considered logged out.
When the old device logs in again, a new unique ID is generated in the database and sent as a cookie to that device. They are now logged in, because their cookie matches. The second device, having its cookie no longer match the database, is logged out.
This solution doesn't require you to access the database on every page, reducing database load significantly.
Add a field for sessionID to your user table in the database.
Set the default session handler before calling session_start() (needed for the next line of code to work):
session_set_save_handler(new \SessionHandler());
On every successful login, retrieve the stored $sessionID from the database. Destroy the old session with:
(new \SessionHandler())->destroy($sessionID);
Get the new session ID with:
$sessionID = session_id();
Store the new session ID to the database.
When starting a session, an authentication is made to the database through a query. If this authentication is granted, one or more session variables are filled with data. This allows the user to transfer through multiple pages without having to re-authenticate - which is great. However, if a session variable that is being used is changed within the database, i.e. username change, access privileges change, the changes are not rippled through to the session (obviously).
How is it possible to get the database changes to trigger, or ripple to, the PHP session variables.
An example is being logged into a website where you have access privileges x that allows you to access pages 1,2,3. Your privileges are now taken away for some reason and you now have access privileges y which allows you to only access page 1. If the user is already authenticated within the site, these changes will not affect the users current session, and will still be able to access pages 2 and 3. This could be an issue in many situations.
Currently my solution to the problem is to re-authenticate the user every page, and update the session variables accordingly. This definitively seems the wrong way to accomplish this task from my limited understanding of how sessions (should) work.
Essentially, I would like a way for database updates to trigger a re-authenticate of the current logged in user. i.e. if user john12 has his database row altered, then his session should require re-authentication.
At the moment I can't think of any way to accomplish this without querying the database every time a page is loaded.
Any tips or solutions would be greatly appreciated.
How I usually do it is by having 4 fields for authentication is my database.
Username
Password (usually hashed)
Token
Logged IP
I remember the user's auth data in cookies. When user has entered the right username and password the website generates a new token and sets two cookies - username and token. On every page load you check if the username, token and logged IP match (to prevent token steal).If one of them isn't right remove all of them and redirect to login page.
In your case if you want to relogin on password change just delete the token when it has been changed.
The only con here is that only one machine can be logged at a given time.
I don't see why you don't want to query the database for user permissions, SQL databases are incredibly fast even with lots of records especially if searching by primary key.
I want to restrict multiple logins of the same user from different locations. How can I identify a user's multiple logins from different locations in the same/recent times? I think some flags and IP checking in a table might be a possible solution, but are there any better solutions?
Update:
I think the session or cookie might help if it for a single machine. Like when users log in for the first time create an activation key and store it, and every other time when users login to that machine, check the cookie value. likewise.
I would resolve something like that by making in user table, a activeKey column. Everytime user is logging in the activeKey is changed ( simple way subchar(md5(time().$username), 0, 16)), and and store it in session. Every time the webpage is refreshed/entered key would be checked. If dosn't match then logout with info. On correct logout key would be set to NULL, so when it could give a flag.
This metod could be combined with IP address, but only IP address could be cheated, same with MAC, and so on.
That is a main idea. There could be additional data like last login date, IP last login date, and so on.
You can have a table containing the IDs and the IP addresses of the users that are currently logged in. Just check against this table everytime someone logs in.
Here's a solution that doesn't require constant database access to work...
(which will avoid the requirement to check the session_id() against the database value every time you request/refresh a page, relieving db/server stress)...
1. On login, grab the pre-existing session_id stored in the DB for this user and do this:
session_id("the pre-existing session id in the database goes here");
session_start();
session_destroy();
2. Then start a new session and save this new session_id to the database, overwriting the previous one. This will logout the previous session on this user if there is one active (effectively logging out the other guy using this account).
Give it a try and let me know if that does the trick!!
NOTE: This is "in theory" as I haven't yet tried it. It's based on this accepted stackoverflow answer. And you should probably manually create the session_id based on something unique to each user, that way you don't wipe out a session that someone else is using that happened to be the same as the session last used by the user you are doing a check for.
I think, just have extra 2 columns for each user - "LastLoginTime" and "IPAddress" in your Users table. If the duration is too short and IPAddress vary then you can give a warning to the user. Additionally you can also inform the City & Country from which the user is logged in.
I would add in the users table an ipAddress column, a LastLogin date column, LogStatus column with boolean values (actually MySQL uses 1/0 for boolean) to check if the user is logged in or not, a Country column (although this could be bypassed by using proxy), and a blockedStatus column, again with 1/0 values, that would check if the user is blocked or not.
Then at log in page, you'd check if the user is logged in then he can't login, if he was recently logged in, and the country is different, then something is happening and you would need to block the account and send a email with a link to unblock the account if the legitimate user was the one logging in.
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.