In our system one client may have multiple operators. However there is a "wish" from client.
One company has an account, however there can be mulitple operators assigned to this company. Client wants us to prepare a solution that only one operator from company can log in to the system at same time. How can I achieve this?
Just by making sure they system has the ability to validate the login on each request. Either
Actively (by querying state -- possibly a database to compare some secrets) or
Passively -- using some form of cryptography and tokens (possibly in the cookie).
Option one is easiest, option 2 is fastest. If you validate on each request you can make sure that only one user remains logged in -- if another user signs in you can invalidate the existing active login -- perhaps with a cooldown period of n amount minutes.
You have to develop some form of login scheme -- kerberos is the defacto scheme -- read this easy to follow tutorial on kerberos Designing an Authentication System: a Dialogue in Four Scenes It should show you what you really need to do.
You could use a database field to flag that they are logged in. Update the field to 'logged in' when they do so, and then update it to 'logged out' when they log out.
You'd also need to monitor login sessions for expiry to update the field if a user never bothered to explicitly logout.
The best approach I've used:
Create a table used to track whether an operator is logged in (e.g. userid and last_accessed_dt)
On each page request by the operator update the last requested date/time
When an operator attempts to login they can only do so if the last requested data/time > timeout period of sessions on your website (E.g. 30 minutes) or if they are the Last Operator User ID ... this way they can quickly recover from a logoff etc.
When an operator logs off have the Last Accessed cleared
When the session times out have the Last Accessed cleared
"I am using WPF application and the server is written in WCF, however this can be achieved. But what in situation when user has an application opened and was inactive for 30min?"
This system is going to be single-user, so I suggest you start a counter thread when a user logs in. When counter reaches 30 minutes, write a value to the db indicating that user has timed out and other users are free to login. Obviously, you should do the same thing when user explicitly logs out.
Related
I am creating a web application which will be used by App's Administrators and for security reasons we don't want to allow multiple active logins from a single user at any point of time.
I am storing session data in the web browser's cookie and want backend to have active user's information who are currently logged in to the application so that on successful login request I can find out if this particular user already has an active session. If that is possible then I can block the login for that user.
One way to do that is storing IsLoggedIn in the Database with LastLoginTime and on each login, I can use this two flags to identify if an active session exists.
Open to other better solutions if any
I think a more robust solution than checking last login times would be to generate and store an id for each new login and then include a middleware to make sure the session's id for each user matches what you expect. That way every time the user logs in on another device the previous one will be invalidated and only one session will be valid at a time. You may even just be able to use express-session's req.session.id.
I would simply like to ask if I'm doing the things right or if it is better if I stop before going in this direction. I have an administrative area in my website and I though to manage login using a table on my database.
When the user correctly login, I then write on a sql table the username, the session id and the IP obtained from REMOTE_ADDR server variable.
When the user ask for a private page that require to be logged in, I lookup the username on my table filtering by IP and Session ID, this return the user of the current user asking for example for "prices.aspx" page on my admin area.
I have then made my so saved records be deleted after 30 minutes. Is this safe enough? Is this a good way to expose my website to hacks? How could I improve the security?
If your site can be hacked, it doesn't matter how your login system works. What keeps a hacker from getting at your data?
Encrypted Transmissions
Never show database names, file names, passwords in front end code.
2 Step verification login to your website and database
The basic principles of logging a member in, or logging someone in to an authorized page are no different.
Whether you delete a record 30 minutes after it's been saved or not is totally immaterial. If a hacker can access that data, saving it in an unsecured manner for 1 second is to long. If you want the user session to time out after 30 minutes, just deleting the database record won't achieve that. So, to your question, "Is it safe enough?". No, it's not.
If your regular member login is safe, then all you need to do is have a field in your user information database, that indicates whether the user is authorized to see certain pages or not.
When your website is first loaded, don't ever load the admin pages unless it's requested, and then have the user give their password a second time. If the user who logged in is not authorized to see an admin page, then don't even load the HTML that allows a user to request an admin page.
We use Grails Spring Security in our application to perform user authentication. If a user loggs in to our application, the rememberMe cookie will be saved. This means, that the user will remain logend in between browser sessions.
How can I check which users are currently online? I read that you can retrieve this information from the Session using SessionRegistryImpl or HttpSessionListener but I have no idea how to implement that. I found this post but I am not sure how to transform it to Grails: Online users with Spring Security
Any idea?
I built a dating application that relies on online users. I created a Grails' Service that keeps track of online users. All you have to do is to create a service that keeps a concurrent hash map, the service is singleton so only one instance for the whole web application. When your user log-in for the first time, you set the user id, and a future time in the hash map. For example:
Key = UserID
Value = Now + 30min
So when the user logs in, you increment his log-in time with 30min and insert in the hash map. For every request the user sends, you update the value of the hash map by looking up his expiry time using his user id. So now if the user closes the browser, he is not going to update the expiry and his online status is going to be invalid. You can have a job that runs every 30min and remove those keys which have an expiry date of less than NOW. Or if you wanna count the online users, just loop through the map and count the entries which their expiry date is greater than NOW.
It's a hash map in memory, very easy to access and manipulate, and it's fast. That works great for me, and since I'm using a concurrent hash map, updates and reads are safe. Hope this helps you get what you want. Sorry that my answer is late but I just saw this question :)
I have a web application where I want users to only be able to use it from one location (meaning a user can't actively be using the application at two locations). Currently I got this working in a very common way by only allowing 1 cookie session to be valid and removing any existing ones when a user logs in. Unfortunately I've been told that my method of only allowing 1 cookie is unacceptable because my users move around a lot to different sites and are tired of having to login every time. An easy solution would just be to allow more than 1 cookie, but I can't do this because I need to make sure a user account is not being used at two locations at the same time.
I'm wondering what is the best way to implement a system like this where a user can't be active at more than 1 location, but shouldn't necessarily have to login at every location they visit.
One possible idea I had was to allow multiple cookies to be recorded, but once a cookie becomes active (meaning I notice that session navigating the application) all of the other cookies are locked out for a certain timelimit like 15 mins. If no cookie session has been active for 15 mins then allow any cookie to login and gain dominance over the others untill it exceeds the timelimit.
Edit: It's ok for them to remain logged in after they leave a location
One way to do this is to log their last ip address and at what time that access was. On each access, you can check their last access.
If the last access is from the same ip, let them through.
If the last access is from a different ip, check how long ago that was. You can then define a cut-off point for how long they need to be idle before they can access it from another location. 15 minutes seems reasonable.
All of this can be done on the backend and this would possibly provide a higher level of security.
The browser allows users to store their credentials. Let them use this feature to log back in without hassle.
No need for a timeout. Allow multiple cookies, but only one active one.
Instruct your users to close the application when they leave their workstations. Make this something that's easy to do. Put a close button on each page or perhaps catch onBeforeUnload and notify the server that the page is no longer being displayed. Do keep the session when the user closes the application, but mark it as currently inactive.
When you get a request with a cookie that belongs to an inactive session, activate that session without complaints if the user has no other session active.
If the user still has another session active, something fishy is going on. So remove all sessions and send the user to the login screen.
(That'll teach them :) )
.. Or is it enough to just check for a session variable that indicates a successful login has in fact been performed?
What are different ways to go about this? The ideal and not so ideal?
Thanks!
Third alternative: HMAC-ed cookie. No need to hit database/session-store at all.
Details.
Even if a user has an active session that is restores via cookie for example, you need to verify his account data.
If you don't check the current database entries for a user, he could possibly login although his profile has been banned or something like that.
The reverse situation can happen if your user opens a session in one browser (at home for example), upgrades his account to some "premium" (or whatever) account with another session (maybe from his office). When he returns home, he would get his old session that has no "premium" privileges.
So, always check the data for your user profiles. I would recommend to check them on EVERY request to your website. Your session data should only say WHO the user is and not WHAT he is allowed to do.