I've a Grails application which is deployed on two servers, and the requests to those servers are controlled by AWS load balancer using sticky session.
A user can have concurrent sessions, so the user might be logged in and having a session on Server A, similarly the user might have a session on Server B.
If a user changes their password, I want to invalidate all the sessions of that user. I'm able to do that on one server using SessionRegistry. How do I kill the same user's session on the other server.
If you're site is API-driven and you are using a token, all you would have to do is invalidate their token; everytime they are requesting anything via an api or that requires checking their roles, it will check the token in your DB (or the DB of the Identity Management SAAS you use) and removing that would make the very next refresh of the page ask them to log back in.
Related
I would like to know internals of tomcat. I configured my web application in 'BASIC' authentication mode. When I logged in for first time, browser asks for credentials. Till this it is fine, may be at the time of login, tomcat reading 'tomcat-users.xml' and set the role. But I am wondering, how tomcat knows the role of the user in subsequent requests. How it keep tracking of the role? Internally is it maintaining some data structure (or) is it keeping this information in session?
I have developed 1 web application but when multiple users are login on the same browser than jsp page of first user is changed by jsp page of second user.
There is no way you can have multiple sessions simultaneously using a unique browser. Each time you create a new session, the session cookie which is used to track the current session is replaced by a new one.
That's because your browser doesn't use a new session for each open tab. If you are using firefox you can install a special plugin to handle that behaviour for you. http://blog.techno-barje.fr/post/2009/12/05/Session-per-tab-in-Firefox/
Explanation on Spring Security FAQ page should answer the behaviour you encountered:
Browsers generally maintain a single session per browser instance. You
cannot have two separate sessions at once. So if you log in again in
another window or tab you are just reauthenticating in the same
session. The server doesn't know anything about tabs, windows or
browser instances. All it sees are HTTP requests and it ties those to
a particular session according to the value of the the JSESSIONID
cookie that they contain. When a user authenticates during a session,
Spring Security's concurrent session control checks the number of
other authenticated sessions that they have. If they are already
authenticated with the same session, then re-authenticating will have
no effect.
I’m developing a system to process financial transactions received by client merchants systems & it is a replacement of existing system which we have purchased from a vendor. Client interface should invoke the user authentication & transaction processing screens from our system.
System functionality as follows,
Receive input parameters from the merchant’s site
Validate it
Authenticate users (users are registered with our system & we should invoke our login screen)
Process transaction
Return status response to merchant
One the response is received client should validate the transaction data from the values reside in the session.
System overview can be depicted as follows,
(click here for full size image)
My problem is client could not retain the session once we are responding to the client. But the same functionality could be achieved by the system that we have purchased from the vendor (we don’t have source code of this to analyse the internal coding structure). I hope something wrong with the way that we are responding to the client.
How can I overcome this problem?
We are using Java 1.4.2, Websphere application server
There are many things which can make a session disappear. I'd suggest to track them and verify if anything went right. This is easier to do if you understand how sessions work.
Session has been timed out. This usually defaults to 30 minutes. This is confiugureable by <session-timeout> in web.xml where you can specify the timeout in minutes. You can implement a HttpSessionListener to track session creation and destroy using a logger.
Session has forcibly been invalidated. This happens when the code calls HttpSession#invalidate(). This is trackable with a HttpSessionListener as well.
Session cookie has been disappeared. Sessions are backed by cookies. If a session is been created, the server will add a Set-Cookie header with session ID. The client should send the same cookie back as Cookie header in all subsequent requests on the (context) path as specified in the Set-Cookie header. This is trackable in the HTTP traffic monitor ("Network" tab) of browser's builtin web developer toolset (press F12 in Chrome/Firefox23+/IE9+). Cookies are accessible for all webapps on the same cookie domain. Also, if ServletC2 runs on a different webapp context than ServletC1, then it won't use the same session. Further, if the "server" webapplication runs on the same domain, then it's in theory able to wipe out all cookies of the "client" webapplication.
The client doesn't support cookies. A well designed webapplication uses URL rewriting with jsessionid to track cookieless clients between requests on the same webapplication. But the second webapplication has to do the same when redirecting back to the first webapplication.
Is it possible to force google to create only one session for a single user?
I have created services in GAE, that uses google id to authenticate users.
Now a single user creating multiple sessions from multiple PCs by sharing
his username/password. I want to restrict this.
In simple language after successful login the application should sign out all other
session for this user.
In gmail there is a link at the bottom of the page by the name last activity details.
On clicking details it shows current sessions and also give option to log out other
session. I want same functionality programmatically.
There is one more option: before logging in detect whether the user is already logged
on?
Have a look at this
http://mail.google.com/support/bin/answer.py?ctx=%67mail&answer=45938
see Concurrent sessions
If this information can be accessed somehow I can take appropriate action.
It's certainly possible.
If you're using Google Accounts for authentication, a user logs in by posting their credentials to Google, and Google returns an authentication token to your site which is then stored as a cookie in the user's browser. The token is good until the cookie expires (24 hours by default) or until the user logs out.
If you want to track multiple login sessions, you can write handlers designed to run after login or logout. If your normal post-login return URL is "/do_stuff", you might change this to "/finish_login?next=%2Fdo_stuff". In that handler you could create an entity in the datastore representing the session, with a reference to the Google Account, the IP address that logged in, and the login timestamp (current timestamp). You can write the session entity key to another cookie in the user's browser. After you're done, redirect to the "next" URL.
After logout you can have a similar handler that checks for the session entity key cookie, deletes the entity, and deletes the cookie.
If you want to show the user that they are logged in from multiple locations, query for session entities associated with their Google Account that are less than 24 hours old (or whatever your cookie expiration is set to).
If you want to remotely log out another session, you might need to write your own version of the login_required decorator that Google offers in webapp.util. Your version would need to verify that the user is logged in, verify that sent a session key cookie, and verify that the associated entity still exists and is owned by the correct account.
There is nothing that prevents you from storing login details in Google App Engine Data service.
As a consequence, you can store all login details for a user in its associated object. As a consequence, I would say there is no difference between GAE and a traditionnal web application - excepted that you'll store login infos in database, instead of letting your web front-end handle it.
I work on a task that involves moving/traversing from one application to another. The applications are in separate JVMs.
While traversing to the other application, I keep track of the session ID. However, as I traverse back and forth, a new session gets created. Is there any way for me to get back the same session, using the sessionId that I retain, when I navigate back into my parent application from a child application?
Environment: J2EE with WebSphere.
As mentioned by Mork0075, the sessionID is tied to the cookie name and the server domain. If you're using the same server domain for two apps on separate JVMs, I see two options to maintain the session when switching between applications:
The long shot:
1) If you're using a database for session replication purposes, you can use the same database for both applications, and the sessionID will be available for both apps. The one problem I see here is that the objects in the session may not be available on both sides, since the code would be different etc. They'd probably clobber the other side's session objects unless you maintained the code and such on both sides so the objects were available.
The likely possibility:
2) Use different cookie names for the session on one of the two apps. By default, sessions use JSESSIONID as the cookie, and when you switch to the second app, it tries to look up a session based on that cookiename and can't find it. So, it creates a new sessionID and sends it back to the browser, thus causing your sessionID to change and not be available when you switch back to the original app. However, if you change the second app's sessionID to something else (say, JSESSIONID2) your browser would end up with two valid sessionIDs that would each be valid on their correct application. You can change the name via the administration console under the application server's Session Management->Enable cookies page.
I'am not sure if this helps, but in a ONE application scenario, you would submit a sessionID with every reponse, save it in the URL, a cookie or as a hidden field. By submitting a new request to the server, the sessionID is also submitted, to resolve it at server side. In my understand switching from one application to another means, that you have to give the sessionID with the user, across the applications. If you save the sessionID in a cookie, this perhaps is not possible, because the cookie is restricted to a certain server domain. So ensure that the session is still valid and the sessionID is present after returning to the application started.
You shouldn't have to do this manually. Most app servers support Single Sign On (SSO) so that you can log in to one application and have access to all the applications in the same SSO domain. The app server will keep track of session ids and link them to an HTTPSession object specific to the web app.
See http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/csec_sso.html