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 :)
Related
I have a requirement to be able to specify session timeouts on a per user basis. (So that it may be a different value for each user) It seems natural to use the 'exp' property on the access token to accomplish this, (as that it's purpose in the oauth spec), but cognito seems to ignore updates to this in the preTokenGeneration trigger. Is there a way to update this on a per user basis? Or do I really need to define some custom attribute that will be checked on the Id token?
Great question. I'm sure you know that since August 2020 Cognito allows you to configure access token expiry time from 5 mins to 1 day. The configuration is per app client. If you were able to split your users across app clients that could be an option (e.g. admins with long sessions login on one page, normal users on another). You could lock the app clients down to certain users using a pre-authentication trigger. That's not a very configurable solution though.
I also wonder what you mean exactly by a session? For example, this would typically mean one of two things. Either your session expires and you have to login again after a fixed length of time (e.g. AWS is 24 hours). Or if you are idle for a certain amount of time (say 30 mins) your session is ended. Could you elaborate on your requirement a bit?
I am creating an application and I am looking for a solution for user authentication (checking if the user is logged in, basically). I am reading online and it seems that many people recommend using a session store/table in your db (store roles, views etc..) vs. just storing the cookie id in the DB in that users column. My question is, what is the difference between storing this data in a "session" store, which is basically just another table and storing this data in your database alongside the other user data (username, passwordHash etc..). I understand that this is useful for data that may change when the user logs in and out again, but are there any advantages to having a session store if my applications state stays consistent across log ins. Thanks.
You need a way to store user data between HTTP requests and sessions helps you to do so.When a user visits our site, it creates a new session for the user and assigns them a cookie. Next time the user comes to the site , the cookie is checked and the session id which is stored in the cookie is retrieved and searched in the session store .Session store is a place where you store all your data regarding your session.So using a session store automates this method and it eases your work.So whenever someone pings your server it will add the session id of the user in your database. I will recommend foe you to look into JWT which is also a interesting way to do authentication.
I am planning to use only cookies (and not sessions) to authenticate users around the private section of my website. I want users to stay logged in indefinitely, unless they logout themselves. It will work like this:
1. Upon successful login I generate a random hash and store it as a HTTP cookie on the user (using SSL). I also store the hash in my database, along with the user id and the user's device.
2. Whenever a new page is requested I check to see if the user has a cookie. If he has I get the hash and search it in my database. If I find a match and the device is the same I assume it's the user and give the page. If I can't find the hash or the device changed I assume it's not the user and ask for login again.
My question: would this method be acceptable, security-wise? I can't see why this would be less secure than using sessions (keeping the users logged in in both cases), as in the end the risk is the same, which is having an attacker discover the hash to impersonate the user. My defense against this is tracking the users device, so the attacker would need to discover the hash and have the same device.
Thanks for your feedback.
What you're describing is basically the session functionality offered by most languages/frameworks.
Just make sure your hash values don't use the time the user logged in as a source of entropy, ie. don't use h(username + login_time) because this could be brute forced fairly easily if the attacker knew the approximate login time.
What language / framework are you actually using? You'll find in most cases there's an option to use the session "functionality" with a persistent cookie (rather than a session one) which would save you implementing this from scratch and possibly creating additional security concerns.
According to Google, there is a limit (currently 25) of how many refresh tokens can be given per client/user pair.
Just to clarify, this is referring to each user, right? Meaning that if I have a million users (!) each user could have 25 refresh tokens active? Or does this mean that I only 25 of the one million users are able to store refresh tokens on my server?
I am referring to the bottom of this page:
https://developers.google.com/analytics/devguides/config/mgmt/v3/mgmtAuthorization#helpme
Ok trying to figure out how to explain this:
When a user says yes they will allow your application to access there data you get a refresh token. You should save this refresh token some place so that you can use it next time. Then you will never have to ask the user to authenticate you again.
But if for some reason you ask the user again can I access your data you will get another refresh token. The first refresh token is still good you can still use that to access there data. You can do this up to 25 times before the first one gets deleted.
Here is a real life example of when this can be a problem:
I have an SSIS connection manager that asks the user if i can access there Google Analytics data. (works with a datareader but i digress). I have run into a problem where the user has to many packages authenticated. Basically they installed my application to many times in testing and the first one stopped working.
In the end i just recommended that they have a dedicated account for using my Task that way they would reduce the change of hitting the 25 authentications.
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.