Web site login in Java + Google App Engine

Go To StackoverFlow.com


I am new to web programming, coming from a video game development background (c++), and am really starting to feel information overload. There are so many competing libraries which all pick something they don't like in some other library, and build an entirely new way of doing the same thing! I am sure there there are good reasons for this, and I don't want to complain, so I'll explain my problem.

To ease my journey, I've decided to start learning Google App Engine + GWT + Java. I like it because it's a distributed server architecture out of the box, and I've chosen Java because of my C++ background.

To begin with I wrote little Twitter-like application because it tests various aspects of web development, namely: REST, JSON parsing/creation, AJAX comms, and HTML generation. It didn't take me too long to create a little site that allows a user to enter their name and password into page in the browser, send the data across to my app, I login on their behalf, grab their friends list, and emit it back to the client as JSON, where I parse it and display it.

Pretty simple stuff.

So, the next step was that I didn't like sending the password the user has entered over the network as plain text (obviously). That got me thinking about all the plumbing I would need:

  1. Authenticate users against my own database, not Google's. (Login/Lost password/Logout)
  2. Enter/exit (track) a session (logged in/logged out).
  3. Store user data in my Google app's database.

All pretty standard stuff that's been around forever. Well I started looking around for a Java authentication library and there were such large, monolithic libraries with huge learning curves, and some are old or not in favour any more... I feel like a total beginner programmer all over again! I just want to have a login page! :)

So then I started reading up on how the plumbing of authentication works, and there is a huge amount to take in. Apparently it's quite common for people to (insecurely) roll their own. I'd rather take a solution that exists and is solid.

So the question becomes, what do people do about this? Twitter supports both HTTP and HTTPS, but defaults to HTTP for its REST API, does that mean people's passwords are flying around unprotected, ready to be intercepted by man-on-the-middle hacks?

I also looked at OAuth, which looks excellent, but it doesn't have a case for just a good old "I don't want know or care what OpenID is". Non technical people I've showed OpenID to are like "wha? I just want to put my username/password in".

As a side note, has anyone had any luck with Spring.Security on Google App Engine?

Anyway, I'm ranting. I just want to know what people do (not in Python, Rails etc, but in good old Java). I'd love to have a login page like Digg, with even an option one day for OpenID :)

Cheers, Shane

2009-06-16 09:52
by Shane


I can't speak to Spring Security alongside Google App Engine, but I can say a few things about it that may be helpful.

First, it is very simple to setup, and they have good tutorials for getting it up and going. Personally, I used the pet-clinic tutorial as a guide for how to apply spring security to my project the first time. I was able to get it setup in a matter of an hour or two and had basic security using my database over a few different pages. Your mileage may vary of course, but worst case scenario you have their full fledged tutorial you can poke and prod to see how it reacts.

Secondly, the library is very configurable. If you search through the manual you'll get a good idea of the things you can do, and I had no problems reworking the areas I needed to change for my project. I have confidence that you should be able to work those Spring Security and Google App Engine together. In general I have been pleased with the Spring source's foresight and ability to interact with other libraries.

Finally, Spring Security supports OpenID if that's something you decide you want to layer in. I haven't played with this portion yet, but from the tutorial it also looks pretty intuitive. The nice thing here, is that you should be able to add that after the fact if it turns out that you should have supported OpenID after all.

I wish you the best of luck!

2009-06-16 15:14
by RC.
Thanks for your feedback, I'll dig deeper. One thing, do I have to take all of the Spring framework, or can I just take the security side of it? It's just that I don't want to have to learn a large library to use one piece of it. If I have to, then so be it, but just wondering up front - Shane 2009-06-17 23:10
You can pick and choose from amongst the various Spring framework libraries. They generally play nice with each other, or most other libraries I've seen as well. My understanding is that you can layer in Spring Security with other frameworks, and we do that locally (technically we're still on Acegi, but whatever), and it works alright - RC. 2009-06-22 18:36


I just stumbled upon your post. You seemed (past tense since it's been a long time) to be confused about HTTP / HTTPS usage and authentication. If you are using HTTP, your password is not being bounced around in plain text. Typically, the login information is POSTed via HTTPS. By this time, a session has been established, which is tracked via a large randomly generated identifier in a cookie. The user is authenticated on the server and their id is stored in the session (stored on the server) to mark that they're signed in.

From that point onwards, the user is tracked via the session. Yes it's possible that a man-in-the-middle could hijack the cookie and assume your identity. This is the case for 100% of sites that work over HTTP but it clearly is just not a problem or you'd hear more about it. For HTTPS, the session cookie can be marked as secure, meaning that it will only ever be sent via HTTPS from the browser. In the past, I've found that browsers behave differently, sometimes sharing the same value for a secure and non-secure same-named cookie (which is a dumb idea). Your best bet is to use a separately named secure cookie to ensure the user is logged in for secure functions on your website.

I agree with you that the JAAS framework is plain awful. It must have been written by a bunch of deranged lunatics with no common sense.

As for using Google App Engine - they will take care of all the authentication for you. It looks like you have no choice but to use Google Accounts which is a shame. It's also a shame that they insist that you redirect to their login page because this breaks the way a GWT app works. I'm currently looking into managing my own accounts because I don't want google to own them and I don't want that disjointed experience on my site.

However, it seems impossible to track a user without a session (Sessions can be supported in GAE but are strongly discouraged to promote scalability in GAE). Without a session I literally do need to send the password and authenticate the user with every RPC request. Google are pulling some tricks to make the getUserPrincipal() method work across their server clusters - and it seems you only get that magic if you go with Google Accounts.

Maybe I'm missing something, but the Google docs just skim over this gaping hole :(

2010-12-22 18:00
by Alex Worden
do you have links to why sessions are discouraged? seems to work for us - HaveAGuess 2012-06-21 00:57
Perhaps this is a new feature to support sessions. In general - if you have a server-side session, then your requests have to go back to that same server instance. In case that instance crashes, copies of your session have to be distributed to one or more back up servers. Logic has to be built into a router in-front of the servers to know where the backups are for each user. Those front end routers also need to be replicated so as not to be a bottle-neck or single point of failure. It's a lot of unnecessary overhead to store data in a session... data that you should probably persist anyway - Alex Worden 2012-06-27 05:46
continued... Make use of Google's fantastic distributed DB to do the work of storing / retrieving data and keep your front end server logic stateless so any server instance can be used to serve requests. Use GWT to keep the session state in the client, not the server - Alex Worden 2012-06-27 05:51
Thanks Alex, we're benefitting from GAE sessions seamless integration with GAE's memcache layer so it's real cheap and easy to get going. Sorry if Im trivialising, I do understand what you're saying, we genuinely have a use-case as the users' datasets are too large to send down the client en-mass - HaveAGuess 2012-07-11 01:10
We also promise them that we don't "store" users' contacts on disk.. so although that's not strictly true as memcache uses disk, it is guaranteed to be temporary. - HaveAGuess 2012-12-20 17:49


hey there, if you wanna work with java you might wanna look into WICKET ... thats a pretty neat java-framework that offers a great deal. it is component-oriented and through the examples pretty easy to understand (see the login-example on the extended example page ... I got it running pretty fast). it also works with other js-frameworks, but also offers its own ajax-implementation. it also has a great mailing-list!

2009-06-17 07:37
by doro
Thanks for the suggestion. WICKET does look very nice, but it also mimics a lot of the same functionality of GWT, which natively supports Google App Engine. Still... It does look very nice and lightweight... I wonder if anyone has tried seeing if they can get WICKET and GAE to play together - Shane 2009-06-17 23:38
Actually it looks like someone has tried getting Wicket up and running with GAE, with some success :)

http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.htm - Shane 2009-06-18 00:13

Ah, thnx for the link. I thought I saw it somewhere, but couldn't remember! Maybe it helps you little bit : - doro 2009-06-18 13:24


I'm trying to do the same using servlet's security-constraint element. In my application basic/digest auth under https is fine.

In the next day I will also try to implement another application using restlet and/or JAX-RS. Both frameworks provides security hooks.

Enter/exit (track) a session (logged in/logged out).

this can be easily implemented using a servlet filter (again, fully supported by GAE)

As a side note, has anyone had any luck with Spring.Security on Google App Engine?

spring security is supported

2009-06-16 10:06
by dfa
Are you able to provide an example of this - Shane 2009-06-17 23:08
for web.xml security constraints yes: check this: http://stackoverflow.com/questions/995035/how-to-define-realms-for-using-by-google-app-engin - dfa 2009-06-18 08:09
Hi, I checked your .xml against the Google docs here:


I noticed they say:

"App Engine does not support custom security roles () or alternate authentication mechanisms () in the deployment descriptor."

You are using in your .xml, so does this work for you?

Also, are you only allowing user authentication against a Google account? Because that's what will happen if you simply set security constraints via web.xml - Shane 2009-06-18 23:21