I have a mission to limit multi login on site(f.e. login from different computers under same username). My PM want to do this with saving session id. How I can do it? I have idea to save flag to database after login, and unmark it after unlogin.. but if browser suddenly or accidentally closed it cant be unmarked. Help me please
You have to store a UUID, the users ID and a timestamp in your databse:
On login create a UUID for the current session of the user (String::uuid();) and Store the uuid in the users session and also in a cookie.
If the users already has an active session or a cookie, read the UUID from there.
A user is now "valid" if:
The user logs in and no database entry is present. The UUID doesn't matter.
The user logs in and the timestamp is "old" (define your own value... 15 minutes?). The UUID doesn't matter.
The users UUID and the user id matches the database entry and the timestamp is not "old".
A user is now "invalid" if there is a different UUID in the database and its timestamp is not "old".
If the user logs out by hand, remove the database entry. If the users just closes his browser he can either resume his session via his cookie or his session (application session, not the browser one) gets automatically invalidated after the timestamp gets "old".
Drawback: If a user wants to switch the computer / browser fast, he/she must use the logout function or else wait for your defined timeout. However, you could also implement a mechanism which logs out the current active user on a session-collision and closes all active processes or whatever you are doing in your application :).
Related
I am having trouble storing sessions in database with codeigniter.
When a user logs in, a session is created and stored in the database. The data is filled in the database. When a user uses the logout button, the session data is emptied, however, the session still exists in the database.
The problem is when a user doesn't use the logout button but just closes the webbrowser. The session data is not emptied, but the user is still logged out. (i hava set this in my config file) The session should be destroyed in the database but it is not!
When a user logs back in after having clicked the 'logout' button, the session that has been created the first time the user logged in, is filled again with the data. So no problems with this.
But when a user logs back in after having closed the browser, it creates a new session.
This problem ends up in having endless sessions, sessions are being created every time a user closes the browser.
something else that confuses me: when I log in with an account, a session is created. When I then logout with that account and log in with another account, the session is stored in the same record as the other account. When are new records in the session table created?
I am using version 2.1.3 of codeigniter.
What am I doing wrong?
//Session config:
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 7200;
$config['sess_expire_on_close'] = TRUE;
$config['sess_encrypt_cookie'] = FALSE;
$config['sess_use_database'] = TRUE;
$config['sess_table_name'] = 'ci_sessions';
$config['sess_match_ip'] = FALSE;
$config['sess_match_useragent'] = TRUE;
$config['sess_time_to_update'] = 300;
You have sess_expire_on_close set to TRUE, so this is expected behavior, and you usually want that in most circumstances. The issue is, a new cookie (hence session) is generated when the browser is closed and opened again. From the CI session class documentation (go to the bottom where it talks about saving sessions in a db):
Note: The Session class has built-in garbage collection which clears out expired sessions so you do not need to write your own routine to do it.
So, it's not something you have to worry about addressing, orphaned sessions will be automatically garbage collected from the DB by the session class. If you want, you can implement code to clean it out via cron, but you really don't need to.
Now, if this presents a problem for specific logged in users (e.g. 'remember me') but you want the session to expire on close for everyone else, you can work around it by manually setting another cookie that far outlasts your session cookie and correlate an item in it within your session DB. This allows you to figure out who the user 'was' and reconstruct the session if it should magically persist for them. There's a bit more about that in this answer to a somewhat related question.
i want to create a user account using asp page in which only one user can login their account ,if that page is currently logged then no one can log in that page after log out only another user can log in that account
This may give you glimps, in database you may add a table UserLogin with two fields UserId, IsLogin. While loggin in any user check for islogin status if it returns true then dont allow user to login. If returns false then allow user to get login. After successful login switch islogin state true.
Hope I have understand your question.
Darshan Joshi's answer is one way to do it, and if you have a simple enough application it may be sufficient.
Depending on the specifics of your application, you might want to think about different angles.
For example: If more than one distinct page needs to only take one user at a time, I would think about creating a new table with a record for each of these pages. This way, you can set a page as logged-in/in-use using the user's unique ID when someone logs in or access the page. When the user logs out/leaves the page (or if their ASP Session expires- users do not always log out cleanly!) you can "unlock" the page again. Not only that, you might reduce database load by searching specifically for the page record rather than any user with a logged-in flag.
I'm implementing session management and am currently storing 4 types of info in the db:
user_id
session_id (hash)
insertion_time (for timeouts)
persistency (if user
has a persistent cookie)
It is possible for the user to have multiple sessions open with different devices. If the user logs out, how do I know which of those sessions I should delete?
What unique information is usually stored along with the info I've already got? IP address does not really work as it could be shared. Should I store the browser info, but what if it is the same?
You should only use a single session id/hash to recognise a session.
When a user logs in (e.g. with username/password) you will tell them what their session id/hash is.
When a user is browsing, they will tell you their session id/hash for every page load. That's how you know it's an existing logged in user, and not some random new user.
When a user tries to loggout, they will still tell you their session id/hash. You can use that to find and delete the correct single session.
You have to store Last access time Last Modify Time of the Session to calculate the Idle time for Session Timeout.
To Identify the User Session you have to store the browser Id. Browser Id and User Id mapping will lead you to figure it out which session of the User you have to delete.
We have a forgot password system that allows a user to create a new password. It is going against Active Directory over LDAPS. Right now once a user goes to create a new password, we have to bind as an admin, change the password to a random string, then bind to the user account with that random string, then change the password to the one they provided. We do this because we have a password history policy of the last 5 used passwords.
This works fine now but the password history has the random strings as one of the previous passwords. Is there any way to bind with a user but without a password? The user would be authenticated before this by a security question.
I do it a different way. I create a dynamic object under the user's entry, expiring in a few days, with a generated uid attribute; send them a link containing that uid; that leads to the change password page, but logged in via a different LoginModule that sees the UID parameter, checks it, and if present and correct logs them in. In other words a kind of 'ticket' login.
The code that did the lookup bound/reconnected itself as the application itself, but that didn't actually matter because the connection for logging in is closed immediately, like all other LDAP connections in the application actually. When anything is done to the user's own entry, e.g. change password, update profile, a reconnect is done as that user using the password which I have saved in the session. When the user does anything else to LDAP it is really the application doing it so an application bind/reconnect is done as above. IOW the application itself is a user (or even several different users with different levels of permission).
Because a UID is much longer than a password, and because the entry containing it expires after a day or two, all this is rather more secure than generating a temporary password and shipping it around. The change password page could also have a security question on it if reached via the ticket login.
There are two password change operations in AD - reset and change. Reset is an administrative operation (which is what you are doing here). When you do a reset, you don't need to supply the current password. Change password is an end user operation whereby the user has to supply their current password in addition to the new password.
If you change your code to do a password reset and run in the context of a user with permissions to reset passwords, you should be good to go. If you need to honor password policy during the reset, there's a way to do this as well with a special LDAP control.
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.