I have user login feature in my application. I used Scala Play Framework as controller. I create sessions using withSession('userId'->userIDValue) for different users. My application has a feature that there will be one super user and super user can delete user. Now what happens is that if super user deletes a user but that user is logged in then that user's session is running till cookie of browser expires. Play Framework is stateless; is there any way to solve this problem?
On incoming requests, I think you need to verify that a user is still active on the Play side, and not just only trust the session.
If that's an expensive operation, e.g., you have to make a database call to verify if a user is still active, then maybe you can use the Play Cache API. If you only have one Play server instance, then it should be pretty easy -- you can just set something in the cache when the super user deletes a user, and have the cache item expiration be longer than your cookie expiration. If you have multiple Play server instances, then it's tricker. :)
Related
I’m currently working on a PoC with multiple Quarkus services and Keycloak RBAC. Works like a charm, easily to bootstrap and start implementing features.
But I encountered an issue that I could not solve in my mind. Imagine:
User accesses a protected service
quarkus-oidc extension does fancy token obtaining by HTTP redirecting, JWT in cookie lasts 30 minutes
User is authenticated and gets returned to the web application
User works in application, fills in forms and data
Data is being stored by JWT-enriched REST calls (we do validation by hibernate-validator)
User works again, taking longer than 30 min
Wants to store another entry, but token from step 3 is now expired and API call fails
User won’t be happy, so me neither
Possible ways to solve:
Make the JWT last longer than the current 30 minutes, but that just postpones the issue and opens some security doors
Storing users’ input in local storage to restore it later after a token refresh (we also would do that to not loose users’ work)
Refresh the token „silently“ in JS without user knowing. Is there a best practice for that?
I missed something important and the internet now tells me a better architecture for my application.
Thank you internet!
Re the step 3. In Quarkus 1.5.0 adding quarkus.oidc.token.refresh-expired=true will get the ID token refreshed and the user session extended if the refresh grant has succeeded
For such use cases, I tend to prefer the reverse of JWT. I keep the user data in a shared data service (a data grid like Infinispan or Redis). So that this data is keyed by the user and available. I do control the TTL of that data in the shared data service.
It can either be specific to an app, or shared between a small number of apps. It does bring some coupling but so does the JWT property structure.
For Quarkus, there is an Infinispan client integration, a Hazelcast one, mongodb and AWS dynamoDB. And you can bring other libraries.
I have been asked to use ember for front end and java rest services as the backend. I am trying to figure out how to manage session for a particular user.
i know there are couple of options like storing in the local store, cookie but they are error prone as some users might disable those features. I want to know what is the preferred approach in normal enterprise apps.
Mine app is simple 15 page app. i need to capture user, and some profile details.
Session are usually more of server side part. You have to just make sure whether the provided session is available or not for every transformed route and request. There is a library which takes care of authentication and authorization in ember https://github.com/simplabs/ember-simple-auth.
I'm using Perl Catalyst with Catalyst::Plugin::Session::State::Cookie and Catalyst::Plugin::Session::Store::Redis. I have at most 2,000 users logged in, but I have more than 2 millions keys in my Redis store.
Most of the authentications are done through an API key. I wonder if each API call gets a new session created and stored (there is likely no cookie in the API call), or if all new visitors to the web site gets a session created automatically.
It looks like a solution would be to set up a very short expiration by default (a few minutes), and override it with a longer expiration when users log in through the web interface.
I was wondering was is the best way to restrict the number of sessions stored to a minimum.
Redis Time out is meant for this purpose, Unless you have any specific pressing usecase to prevent all your sessions from expiring (I Can't see any) you should set it to practical time limit (default:300).
However this has problems in older version of redis so before testing this feature you need to get latest redis installed to fix it.
It seems that basic functionality such as user login, can not be done in simple manner: to have username and password field in form on client and based on that to create store.readPathAccess model access rights. Also, how to check if user is logged in to implement access rights on routes?
Based on examples and (poor) DerbyJS documentation, if I understood it correctly, you have to implement login in server module (lib/server/*) because:
store.readPathAccess must be used in server side
you want to store data in model session (which can be read only on server side)
But many questions arise:
if it has to be done on server side, how to get and store client form data on server side without having problem with second item below on the list (I have done it with manually submitting data to server-only route, but can not then save it in model with local key because I have to redirect to client route after that and local model data is lost)
how to read later that data if it must be stored in session?
even if the store access rights for model is managed, how to check if this specific user is logged in when in client routes?
I'm quite confused at the moment... liked Derby principles, but this authentication problems are playing with my nerves seriously.
I know I may not be quite clear, but there are many points to go in details and if anyone can help I'll gladly give more required info.
Thank you,
Eddie
I found this library today called derby-auth.
It uses passport for signing in and has a good example using a simple register and login form.
What it does is to set some routes on the server for logging the user, and a middleware to tell the client if it's logged or not.
It does have some bugs (a few callback calls missing that break some things), so i wrote my own based on that, but must clean a lot of things before uploading anywhere.
i'd be glad to send it to you if you want to, though.
The most current library is https://github.com/derbyparty/derby-login
It has been updated pretty regularly and works with derbyjs 0.6
On my iPhone Facebook app I think I've only logged into it once.
On my Mint financial app, I've logged in once. whenever I load it back up, I give a four digit PIN number which was setup in the app, and I never have to log in again.
I'm building an application right now where this type of behavior would be highly beneficial.
Do they just set an auth cookie of some sort and just set it to expire way into the future? Or is there another way of handling this?
Thanks!
You can use the iOS KeyChain to securely store credentials as well. This can be simplified by using this code found on github ( https://github.com/ldandersen/scifihifi-iphone/tree/master/security/ ) , with some basic instructions found at http://gorgando.com/blog/tag/sfhfkeychainutils
That depends on the context of your application. If you authenticate against another API, the supplier of the API usually provides you with some sort of authentication key which might expire after a certain time. You would store this key in your application once the user performs the authentication step and reuse it for every request.
Basically, the data you have to store and the time before your user has to re-authenticate (if ever) depends on the supplier of the API you're using.
I can't speak for Facebook or Mint, but the simplest approach is to use a cookie / token and store it in NSUserDefaults.
When the application is launched, see if token is still valid. If not valid, force the user to sign in again.
I am taking a stab in the dark here, but:
I am assuming the login information is encrypted and then stored on the device somewhere. Upon creating a new instance of the app this data is sent to the site for all of the oauth/login/etc stuff. Once this is done the Facebook app stays on until: 1) the device is turned off, or 2) you manually quit the application.
Maybe this will start to help you, but I am sure better answers will come.