in login window and Auth managment i cant set lifetime correctly. how to set that before creating a session such as:
Config::set('session.lifetime', '60');
second parameter is random and user can change that in login window
You definitely should not change server's session lifetime in Laravel instance for each individual user. Instead, store session expiration time for individual user somewhere in database, next to the user data with the timestamp of last user activity. Whenever difference between last user activity and new request will be more then expiration time (that you saved in database), do Session::flush()
Related
I have a large application which expires the session data after 30 minutes of idle time. Now I want to call a function before the session expiration.
My Reason for above question: I am storing a unique id in database for some purpose. When the user clicks logout, I will delete that ID. I want to delete that ID even when the user session expires after idle time.
As far as i know , it will be bad practice to set a "counter" for users to check if their session is expired.
If you need this ID to see who is connected in your administration aria , one possible way to do it is by checking the session expiration on loading admin page , and then delete the expired sessions rows then showing only active sessions.
So my idea is that while you are not using your admin dashboard it is okay that some sessions ID's still in your database , once you try to see who is online , the check function is called and clean up your data for expired session.
THAT IF YOU ARE USING THAT ID FOR SOMTHING LIKE THAT SINCE YOU DIDN''T SHARE THE WHOLE REASON OF WHY YOU NEED TO DO SO.
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.
I have a webapp that uses persistent cookies to allow a user to stay logged it.
I am using the Improved Persistent Login Cookie method.
https://www.programering.com/a/MDO0MzMwATA.html
https://www.experts-exchange.com/questions/29006560/selector-validator-cookies.html
When a user is logging in through the LOGIN form and has asked to be remembered I generate a random selector and a random token and add these to a table called Session in my DB along with the userID and other values(IP,time,browser,whaterver). I also set a cookie called KeepMeLoggedIn with the value selector:token and expire in 30 Days.
When the user returns to the site (before or after the PHP Session/Code Igniter has expired) I check for $_SESSION variable, if none found I look for my KeepMeLoggedIn cookie. If the cookie returns a value I check it against my Session table to see if the selector and token match. If they match I reset the token and store it back in the DB and cookie is updated to the new selector:token value and the login process completes.
When a user logs out I destroy the cookie and session and delete the entry in the DB for the selector.
All this is working great except for when a user deleted the cookies manually. The record in my Session table is orphaned. In testing my system I ended up with 50+ records in my Session table that were from the cookies I manually deleted while testing the logic. Since I manually deleted the cookie the selector was not available to the code to be deleted/removed from the Session DB.
So here is my questions:
1) What is a usable approach to handling these orphaned record?
My first thought is just purge the Session table of any date older then my chosen expiration date for the Remember Me function, either when a user logs in, or in a chron job, or whenever
Are there any other ideas here?
2) Is this a vulnerability in the overall model that can allow a hacker to:
create an account on a website
x=1
while x <2
-> login and ask to be remembered
-> delete the cookie
do();
And end up flooding the website's Session Table till the site is shut down, adding 1,000 and 1,000 of record over time??
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.).
We are using PHP and storing session data in memcached. Is there a way to invalidate all sessions by a given user id? The use-case is, when a user changes their password, we log them out, however we should also be invalidating every other session under that user id as well.
Is this possible?
I think you would have to add a check on every request to make sure the user context is still valid.
First thought is to have a record in a backend store that contains a timestamp that the user password was updated. When a user logs in you can write a cookie with a timestamp or store it in the session. Upon subsequent requests/checks, as long as the cookie/session date is newer than the password change date it passes. When the password changes the date on the backend record is set to current timestamp and the next check will fail and destroy the user session.
So in this context the actual invalidation wouldn't happen until the next request comes from the old session.