Saturday, May 3, 2008

from google.appengine.api import users dilema

App engine comes with a library to handle user authentication off of Google's gmail servers. The idea is that anyone with a valid gmail account would instantly get access to your application, and you don't have to sweat the details of session management, password recovery, setting up CAPTCHAs and filtering out spam accounts, or any of that truly annoying stuff.

Authorization is handled through an admin console for your application. You can specify which libraries/urls require different levels of access (choices are "none", "login", or "admin") and help protect different parts of the site. Pretty simple, and pretty flexible.

There are a couple of hitches in the plan, though. First off, there's no unique identifier for a user account other than the email address. The doco claims they're mulling solutions, but nothing appears to be promised or hinted at (note to googledudes: gmail auth is a good starting point, add in support for creating and managing personal certs for the win). Second problem is that there's recently been news that spammers have found a way to beat the audio CAPTCHAs google is using and thus have been establishing spam accounts with it like it's the new hotmail or something.

A third problem really isn't that huge of a problem, but it is something to keep in mind: the standalone webserver in the SDK merely checks for the existence of a gmail account.. it doesn't do any password validation. Worse, you can give it a non-google email address and it just uses that. The problem here is that kind of nerfs the idea of releasing the source code for a web app and allowing people to run their own standalone instances of it on their own hardware.

One solution to all of this is to simply use your own user authentication and authorization system and clip out google.appengine.api.users from the equation. But now you've got the hassle of session management again, only this time no database to use to solve the problem (the BigTable datastore *could* be used here, but you wouldn't want to do it because writes are much more expensive than to a traditional database making ill-suited for temporary data). You could stand up a server somewhere else, but now you've got the cost and complexity you were trying to avoid by using GAE in the first place.

Using something like Google Gears and allowing users to have offline access to your app is one possible solution, but offline support isn't the same thing as owning your own instance of an application.

For the ideas I've got and that I'm monkey around with, this isn't really a deal breaker, but it does limit options for future projects.

Next GAE whine session: how having multiple places to handle URL routing can cause headaches. :)

No comments: