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

• java
• google-app-engine
• login

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!

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 :(

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!

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