Web site login in Java + Google App Engine

Question

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

Answer 1

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!