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.
Related
I want my website to have a checkbox that users can click so that they will not have to log in each time they visit my website.
Remember me
Remember-me authentication refers to websites being able to remember the identity of a principal between sessions. This is typically accomplished by sending a cookie to the browser, with the cookie being detected during future sessions and causing automated login to take place. Spring Security provides the necessary hooks for these operations to take place and has two concrete remember-me implementations. One uses hashing to preserve the security of cookie-based tokens and the other uses a database or other persistent storage mechanism to store the generated tokens.
Keep me logged in
When checked, the option Keep me logged in allows you to force your browser to remember your credentials to be automatically connected when reaching the login page. By default, your credentials are stored for 2 weeks. After this period, you will have to log in again.
I'm working on the design of a program using Play framework for Java. It's a website that requires users to log in and it needs to prevent a user from logging into an account that is already logged in.
When a user logs in, the username is stored in the Cache (using memcached). When the user logs out, the username is disacarded from the Cache. If a login attempt is made for a username that exists in the Cache, the login attempt is rejected.
For example, a user logs in with the username "joe". Someone from another computer attempts to log in with the username "joe" and it gets rejected because "joe" is already logged in.
Simple enough, except when a user closes their browser tab, then they are locked out because their username still exists in the Cache.
So, using javascript, I've captured the window.onbeforeunload event to redirect to a route that runs a Java method that clears the Cache. The problem is that window.onbeforeunload is fired when the user clicks a link or reloads the page. So, if the user reloads the page, they are logged out, or if they click on a link within the website, they are logged out. Is there a way to prevent that from happening?
Edit:
I am using Security.Authenticated to ensure people can't access the website unless they have a session in their cookie. I have a BaseController that extends Controller and all of my controllers extend BaseController (except the one that handles the login page), and the BaseController is annotated with:
#Security.Authenticated(Secured.class)
Secured ensures that when somebody tries to access the website, if they don't have a session, they are redirected to the login page. Once they log in, a cookie is created with the session and Secured will allow them to access the page.
What about expires time in the cache? And to prevent a key be deleted, even if the user is still active, you can create a composed action that refreshes the cache in every new request.
Alberto
I was wondering if there was a "standard" way for handling persitent HTTP sessions in a GAE based web app. Let me explain my issues.
If I only use this.getThreadLocalRequest().getSession() to get a session, this session will be automatically invalidated once the user closes the browser.
If I go with Cookies (so the session will persist until the cookie expires or the user erases his cookies), I need to have a kind of mechanism for validating that the sessionID stored in the cookie actually belongs to a valid session. I've thought about storing a key value pair of sessionID, HttpSession in a concurrentHashMap, but now I run into the problem that this hashmap will be available only for the current instance, therefore I might run into consistency problems.
The last solution I thought of was keeping track of the session in the datastore, but it seems pretty ridiculous to me having to query the datastore each time I receive a request.
Maybe I'm totally out of the track and there's a really simple way to achieve what I'm trying to do: Http sessions that persist across browser restarts and multiple gae instances.
Thanks!
Rodrigo.
You typically use a cookie to implement remember-me. The idea is to generate a random and unique cookie for an authenticated user, store it with the rest of the user information in the database, and send the cookie to the client browser.
Now, when the client comes back 5 days later, the cookie is sent with its first request to your application. At this time, if the user is not authenticated yet, you can extract the cookie from the request, find the user in the database who owns this cookie, and automatically authenticate him as if he sent his credentials.
This solution doesn't need to modify anything to how the sessions are handled by GAE.
I want to implement a stay logged in or remember me in my jsp login page. I am using container based form authentication. I think I need to I have to store users' data such as userid and token - a status information to determine whether as user is logged or not, into the cookies.
Also I heard that we should not store users' password even it is encrypted.
If I store their password and userid, I can sigh them in automatically by submitting the data to servlet before I show the login page to users.
If I do not store their password, what method could I use to sign them in automatically?
I would suggest that you not create your own framework for this but rather use something like spring-security or Apache Shiro since the security of your application is pretty important and not something you generally want to build from scratch.
If this is purely for educational purposes, I would suggest looking at the code for the two mentioned applications to see how they handle it.
I have seen this implemented as a secure token in the cookie (with expiration date) whose value is also stored on the server for a set period of time and associated with a specific user account. When the user returns to the site with that cookie, the server will compare it's token value to that of the cookie and let them in if they match (and it is not expired).
Again, it is best to use pre-existing and tested libraries for this kind of work.
Best of luck.
I'm building a Google App Engine for Java app using Federated login.
When a user has logged into my app using an OAuth provider I get a User object back [http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/users/User.html].
I want to persist a link to that user in the datastore. However, what do I use as the unique key? Is it the getFederatedIdentity() or getUserId() ? There is hardly any JavaDoc on either. Obviously when a user subsequently logs into my app I want to retrieve the Object I have saved to the datastore.
I understand the federatedIdentity field, which I understand should always be populated (I only allow federated logons). However, if that's the field to use to link my details to the logged on user, then Google leaves this empty when testing on the local server... so that wouldn't be much use.
What is the getUserId field - how does Google set it? Will it guarantee to stay the same if the user's federated identity stays the same?
Thanks a lot
From the Users Java API Overview
While a user is signed in to an app, the app can access the account's email address or OpenID identifier for every request the user makes to the app. The app can also access a user ID that identifies the user uniquely, even if the user changes the email address for her account.
sounds like getUserId() is the best choice.
You don't need to store either - you can store the User object directly in the datastore. See here for a list of supported object types.