In my grails application using shiro, I'm using cookies to store the session data including authorization.
When a user tries to log in without accepting cookies, the login works, but then (as expected) the session is lost again and the user is logged out.
I don't want to change this behavior in general, I just want to display a notification to the user that his Browser needs to accept cookies.
So is there a way to tell that this user has been the one who TRIED to log in after the session data is lost, so that I can display a respective message?
I think running a test whether cookies are accepted on every page is a bit too much, therefore I'm heading towards the solution at login only.
You could use the grails session to store the current state of the user. Then, on login, check the grails session and determine whether to show your message or not.
Related
I wish to record the login and the logout timestamp for users.
I understand that as soon as a user hits the login page a new browser specific session is created & sessionCreated(HttpSessionEvent se) is executed. When the session is invalidated that session gets destroyed & the sessionDestroyed(HttpSessionEvent se) is executed. In this scenario recording the login and logout timestamps will work perfectly.
However, say, the user is logged in but closes the browser window. The next time when the browser is opened a new session id will be generated and the user needs to login again. Hence, the previous login-logout record for that user will be incomplete and a new record with the current session id will be inserted in the database.
How do I tackle this design issue? I read some answers where AJAX polling & JS onunload were discussed but those did not seem to be a reliable solution.
Also, on the other hand, is there a way to keep the session alive even on browser close?
Thanks in advance.
Session can be kept recorded on users browser via Cookies.
It basically allow use to re login to the system without having to authenticate itself. In this case you can store the bare minimum state information you need to restore when the client open the browser again.
But the session id's is definitely going to change.
In CakePHP a the Session times out it, not unreasonably, trashes any custom data in the stored Session.
However it also sets up an Auth.redirect so after the user has been forced back to the login screen and completes the login, they are then (by default) redirected back to the page they were on before the session expired. This is problematic if that page relies on some of the custom data that was stored in the Session but is now no longer available.
My simple solution has been to force the user back to the home page for authenticated users by deleting the Auth.session key in the Session. But this isn't a particularly desirable behaviour. It would be preferable if I could return the user to the place they were before the Session timed out.
Nevertheless, I like the idea of a user having to re-authenticate if they abandon their Session for too long.
So, what seems to be needed is for CakePHP to require a re-authentication of the user but to not actually expire the underlying Session and this leads to a couple of questions:
Is there any way to have CakePHP require a re-authentication of the Session, as described, without timing out the session (i.e. setting a long timeout on the Session)?
Is there actually a better way to store the information required for page transitions (e.g. the ID of the parent record for a given model so that saveAssociated can be used) other than to store these in the Session?
Thank you for any guidance.
Passport by default allows the same user to login from multiple browsers and have unique sessions created. How can I configure it to destroy the first session when the user tries to create a second session?
Currently I'm using the 'Sessions' model to add the username to the record and upon subsequent login check by username if the sessions exists. But this increases traffic to the db. I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified. I'd be thankful for ideas around how to achieve tweak with express for this purpose or any other workaround/suggestion.
Much thanks!
I saw that at least 4 users upvote this question, so I decided to create passport-strategy for that. The new strategy called passport-one-session-per-user. It's open source strategy you can access here: https://github.com/AminaG/passport-one-session-per-user
How to use it? add it right after session. For example:
app.use(passport.session())
var passportOneSessionPerUser=require('passport-one-session-per-user')
passport.use(new passportOneSessionPerUser())
app.use(passport.authenticate('passport-one-session-per-user'))
Not need for settings, or configuration.
How it is works?
The strategy, created an array that contain serializaed user objects, and sessionID.
Every time user logged in, the strategy check if the user already logged in. If so, it's flag the other session. The next time the user in the other session make a request, the strategy see the flag, and log the user out.
I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified.
I believe the session model loggs the user in, and saves only that logged-in-ness in the session cookie. The server itself has no clue about who is logged in, but just checks this state in the (signed) session cookie provided by the browser.
You can write your own Passport.js strategy to handle it differently.
My web application requires a user to be logged in to view any webpage on it.
When a user logs in I store, in sessions, their username and password for retrieval later on. This all works fine but, if I rerun my project it seems to skip past authentication and go straight to the controller for that action.
What I presume is happening is that FormsAuthentication.SetAuthCookie(userName, createPersistentCookie); is remembering that the user is logged in but my sessions aren't updated.
How can I trap this scenario and update my sessions accordingly?
There are many ways of going about it.
First, you can choose, not to persist the cookie. But this will still cause the exception if the session has not expired and you recompile your project. Recompiling the project destroys the session state.
Though putting the password in session state is not the preferred way of going about it, I am sure you would have a valid reason of doing it that way.
However, if you want to do it that way, you can override the Application_AuthenticateRequest event in Global.asax. This event fires every time a request comes in and you can check if the request is authenticated (using HttpContext.Current.User.Identity.IsAuthenticated) and repopulate the session state.
By the way, can you elaborate why you need to store the user password in session state?
If I am correctly understood the issue,you can have base action class so and move the authentication mechanism there.So for every request this base will be invoked so you can make sure that the authentication mechanism is not skipped.
I'm currently making a site using GWT, being hosted on AppEngine. I'm making it with my own logins that I'm making (I know Google provides something with GWT, but I need my own login system), and I've been trying to figure out sessions for quite a while now. I've found a few tutorials, and one of the sites that I was reading is http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ
There is a section there on "How to Remember Logins". I know how to get the session ID and store it on the client in a cookie through an RPC call. What I don't understand is, eventually after a day or so, the user comes back and I'm supposed to get the session ID from the cookie and send it back to the server. What am I supposed to do on the server in order to securely evaluate if session ID is still legal, and pull up all the necessary information about the user?
Additional questions:
1. What would make the session ID change?
2. What if the user was on a laptop, and the user went somewhere else. Would he still be able to be securely logged back in without having to type in his login and password again?
Thanks!
~Scott
Similar question: question on GWT, Cookies and webpage directing.
One important thing you should remember: don't rely on cookies alone - transfer the session ID/token in the payload of the request too and compare it with the cookie value on the server side. This will prevent XSRF attacks. That's the sort of thing you should be worried about.
The policy on how to deal with session IDs depends on how seriously you take security in your application and what type of application is it. For example, you can login with the same token on GMail from different IPs - I presume they allowed this because it's common that the user's IP changes over sessions. They did however add a feature that allows you to see from which IPs the user logged in recently. And don't forget about users with dynamic IPs (quite a large number) - if you keep track of tokens and IPs you will basically disallow those users to be kept logged in between sessions.
What am I supposed to do on the server
in order to securely evaluate if
session ID is still legal, and pull up
all the necessary information about
the user?
You should keep track of the session IDs/login pairs in your DB.
What would make the session ID change?
Either it expires or the user tries to log in with a token that is not bound to their IP. You could add your own rules too - like the number of logins, etc. For additional security, you can generate a new session ID/token on every new login/session (the user authenticates with the old token, the server checks that it's valid and sends back the user the new token he/she should use from now on).
To remember logins you need to securely generate a unique session id. Normally, this is placed in a cookie. I would recommend using a framework that does session cookies for you. Getting it wrong can leave your site wide open to abuse. Things to consider include:
Do you need to worry about cookie stealing. The user's IP address should be encoded in the session id, or linked to the session id. Check the IP address on every page access.
Ensure your logins are on encrypted sessions. Otherwise, you expose credentials in plaintext on the network.
How long should sessions last. They should time out after a fixed time limit. This can be hours or days long.
Remember me should be different functionality on a different cookie. It needs to contain something that can be used to indentify the user. Depending on your security requirments it may need to be an encrypted value. This cookie can have a longer timeout.
Answers to your additional questions are.
Nothing on the client side is likely to change the session id. The session id should be regenerated every login.
Depending on how secure the session id is, they may have to login. Secure session cookies often encode the IP address to prevent cookie stealing. If so, the laptop user would need to login again.