Spring makes removing cookies on logout entirely painless, you just add
<security:logout logout-url="/j_acegi_logout" logout-success-url="${server.environment.baseUrl}j_spring_security_logout" delete-cookies="USERPREFS"/>
Now, USERPREFS is the name of the cookie in the app that stores information for a specific user, and is set to be a session cookie only. When the user logs out, that cookie is removed, so other users won't have someone else's preferences applied. However, I noticed that in the case of a session timeout, a user could come along to the computer terminal, try to refresh the page, get redirected to the login screen, and now they're back in the app with the previous user's cookie!
Obviously when there is no cookie, the values are being supplied dynamically by the app, but to avoid a few extra db calls, I check to see if the cookie already exists in the request, and use it if it does. I can stop doing this, but it would be nice to just be able to set that cookie to also get removed when the application has to reestablish a new session, especially when the user switches
I believe USERPREFS is logged-in user's preferences. In that case you cannot use the value set in USERPREFS until the user logs-in. If that is the case, you should set the values from user's preferences saved on the server side when the user logs in. That way, though you have USERPREFS cookie, you don't use the value until the user logs in. When the user logs in you set the logged-in user's preferences in the cookie so that currently logged in user's preferences are used.
Related
In a spring security application i am navigating to the login page and entering my credentials and getting logged in.Now again if i open a new tab in the same browser and navigate to the login url it shows me the login page.If I enter another users credentials and login my previous Jsession ID(ie: the one created in the previous tab) is getting overridden with the new jsession id.Upon refreshing the previous tab the session is overridden.
I want to implement that if a user is logged in already in the application, upon navigating to the url again in another tab on the same browser the homepage of the application should open.
Please advise as how I can accomplish that?
Since the server uses the cookie to map to the current session, you'd have to control how the browser sends cookies. Every time a request is sent to a website from a new tab, most browsers will send all the cookies it has for that domain. Since your server received the same session cookie, it will treat this request as being in the same session. There's no way it can tell the difference.
Therefore, as far as cookie-based web sessions go at least, you probably won't be able to force the creation of a new session upon opening a new tab.
I have this web app written in AngularJs that uses cookies to authenticate the requests in a REST API.
Once the user logs in, the cookie is received and saved in the browser and all subsequent requests send the cookie along to the server. There is a 'User' service/object that saves the isLoggedIn and username values (for UI display/flow). Now, if I refresh the 'index' page, the app restarts. This means that my 'User' object will be cleared. I can check the existence of the cookie and, if it exists, I can re-set the User.isLoggeIn as true and go from there, but I still need to get the username, id, etc. So, my question is: should I create some sort of 'ping' endpoint in the API to verify if a cookie is valid? And if so, the API would send me back the user id and username... OR should I persist the user data in LocalStorage (or some similar cross-browser thing) and just assume the user is logged if the cookie exists? Any other subsequent requests to pages that need authentication would be automatically verified. So, this question really only applies to the scenario where the user refreshes the index page - hence, restarting the web app. I want to know the user data because I want to show a 'user homepage' instead of the 'public homepage'.
What do you think?
You should depend on the server for this. Creating something like GetCurrentUser method on the server. If the user is logged on this returns all the properties of the user.
You should even use this server api to get the user data after authentication completes. So the authentication become two step process first the user is authenticated, on success another call is made to server to get current users details.
Using client side local storage for this would not be ideal because you need to do lot of book keeping, in terms of cleaning the logged in user on log out or session expiration.
Also cookies from server would have expiration times an all, and making decision just based on cookie existing on local storage may not be optimal approach.
Looking at the OWASP Session Management Cheat Sheet, every time a session expires, must a user go through the same Pre-Auth --> Auth --> ... steps to make a new session?
For example, if a session expires and the web app requires authentication, will the user have to log back into the web app before getting a new session?
Sessions are maintained with cookies.
Http is a stateless protocol. Every request to server works in isolation. No request has any information about previous request.
Say a user named A logs in to the site. This site works with session and sets session data for a user. Internally the server creates some value and associates with a particular user. A value 12345 is computed and associated with user A. The server decides to give this value's name as sessionId. It sends sessionId in the cookie and this cookie will be stored on the user's browser. Next time the user A makes a request this cookie will be sent to server. Server reads for cookie sessionId, and finds it. Then it sees with what user is the value in this cookie i.e 12345 is associated. It finds that this value is associated with user A and so its the user A, who is making the request.
Say this cookie expires, can be for various reasons. Either user deletes the cookie on his end. Or after certain days, server cleans this association between user and the session. In that case server will not be able to know who is the user making the request. And hence the entire flow of login by user, seesion generation will have to take place.
So, yes, if a session expires and the web app requires authentication, user will have to login again
Yes, the user has to log in again. Also, it's important that a new session gets a new session id, as an attacker could have gained the session id. If you re-authenticate the same session id, the attacker would gain access as well. See session fixation attack.
Depending on the safety requirements, you might also have to implement a maximum time to life for every session. Usually an attacker would take over a session and try to keep it alive as long as possible. Expiring the session after a certain amount of time, even if it is active, is an effective way to ensure that attackers can only have access for limited time.
I am using Asp.net MVC 3 in my project. I have a simple login page which takes username and password and after successful login, take me to the required page.
The problem is when I press back button from my browser and then press forward button again and again, it takes me again to the page without getting username and password from the user.
I don't know, may be it is the problem with sessions state. Because I didn't make any sessions and I don't how to make it.
Please anyone out there help me a bit to mitigate this problem.
Your session id is stored in a cookie, on successful authentication, the cookie gets stored on your machine, when you move forward in history, it doesn't get removed.
If you explicitly clear the cookie on each visit to the login page using:
Session.Abandon()
this will kill the authenticated session and create a new anonymous one, which shouldn't have access to the restricted page
After the username password login form is submitted (presumably with some kind of encryption through https) how does the server maintain the information that the user is logged in?
The user submits the login form and the server authenticates the user and returns a page. But when the user clicks on a link on that page how does the server know the request it is receiving is coming from someone who is authenticated and therefore the server knows its safe to send the html for that new page.
The act of logging on will usually result in the browser getting a session cookie passed back. It's this cookie that the server uses to identify which session (if any) belongs to the user.
If cookies are disabled on the clients browser, most web programming frameworks will cope by sticking a session ID onto the URL.
the username and some flag like is_logged are stored in the session.
on any page you should check those variables from the current session.
on logout you clean the session or destroy it, thus your protected page is in accessible.
good luck
Arman