Using sessions in Google App Engine with mobile client

Question

I'm looking to implement session support for Google App Engine using either gae-sessions o r webapp2 sessions , which ever makes more sense. However, I don't really understand how it works. In the sample code, the most work they do is:

 session = get_current_session()

I thought the whole point of sessions was to authenticate users. Here is my situation:

The user will only be able to use the iOS app when logged in. After the first time the user logs in, rather than sending the user's password for authentication every time, I've read that this is what session ids are for. So now, how do I use these frameworks to do this?

• Isn't there supposed to be some id?
• What do I send back to the client after a successful login?
• How does get_current_session know who the user is?
• What does the client send to the server with every request?
• What if the user is signed in from multiple devices?

Keep in mind that the client is not a browser, but a mobile application. I'm just not understanding how this all works for this case.

Answer 1

I thought the whole point of sessions was to authenticate users.

No, sessions are used to identify requests that belong to the same browser. It does not identify or authenticate users. This is the job of your code. Sessions usually work via Cookies: on first request servers sends a cookie, then on all subsequent requests browser adds cookie to the request. That's how server knows that a series of requests belong to the same client (browser). For this to work in your case, your Android code should use cookies .

Isn't there supposed to be some id?

Yes, after login you'd normally get some user ID, but this is specific to login procedure. Also this has nothing to do with sessions. Session is basically an object on the server side that is always the same when requests come from the same client. You can store some attributes into the session object: normally after user performs login, you'd store their user ID into session to easier identify requests coming from the same user. When user logouts, you'd delete the user ID from session.

What do I send back to the client after a successful login?

Enable sessions on server (= pick your library ) and enable cookies in Android code . Then sessions will be automatically handled between your client and server. After successful login just store user ID into session. On subsequent requests just check if session contains user UD.

How does get_current_session know who the user is?

It doesn't. After login you store some user-related data into session and on subsequent requests you can check for this data.

What does the client send to the server with every request?

For sessions to work it should send a cookie. This is done automatically if you enable cookie support in Android HttpClient code (link above).

What if the user is signed in from multiple devices?

Multiple clients would result in multiple independent sessions. It's up to your server code to identify sessions that belong to same user (= multiple sessions would have same User ID stored in them).

Answer 2

You can use webapp2 to handle authentication for you. There is a module in webapp2_extras called auth. It will help you to register, login and logout.

Here is my detail answer:

Handling Sessions on Google App Engine with Android/IPhone

Once you've done login with app engine. You just need to store the authentication cookie and send it to subsequence requests. On server side, you can check user is logged by:

from webapp2_extras import auth
if auth.get_user_by_session():
    #Logged in      
else:
    #Not logged in

Note: Another simpler approach for those using Android is use Google Authentication on server side and AERC (App Engine Rest Client for Android) to help you authenticate with server.

Hope it helps :)

Answer 3

First read up on HTTP cookies http://en.wikipedia.org/wiki/HTTP_cookie

A session is really just a data object on the server. Think of it as a python dictionary. It's should be persisted to the datastore and memcache. It has an id of some kind, which is usually stored in an HTTP cookie that is passed back and forth between the server and the browser.

The session handling library essentially does the following when you receive a request: - Looks at the cookie and gets the session id - It - Pulls out the session data for that id from the datastore or memcache, and inserts it in the 'request' object.

It also handles bookkeeping like saving the data, and verifying the cookies haven't been tampered with.

Depending on the session library you use, it may be up to you to associate a session with a user. Often times, you won't necessarily need to explicitly associate a session with a user. You may have multiple sessions for any one user if they are accessing your site with multiple browsers. You do however, want to be careful to terminate sessions when a user logs out, as well as starting a new session when a new user logs in.

Since sessions are generally disposable, you will eventually have a bunch of unused or expired session in your datastore, you'll need something to clean them up.

As far as you're concerned with a mobile app, yes your mobile app needs to act like a browser, store the cookie data, and pass it back up to the server with each request. If you're using the android HttpURLConnection, use the optional CookieManager to handle this part.