Tuesday, May 01, 2007

Form Authentication and REST

I started playing with AuthKit inside a Pylons App last week. AuthKit works nicely, just like TurboGears identity management, but they both share a common problem when working with RESTful controllers.

When a 401 error is raised, the framework takes over and redirects to a login form. The login form then checks the validation, and redirects back to the original page, in effect converting a GET request into a POST request.

In your Pylons app, this could have the effect of calling your create method in your controller, rather than the index method.

I think the lesson is: only raise 401 on methods which are called by a POST request, or use standard HTTP Authentication systems.

Which is the lesser evil?


Anonymous said...

I'm far from a web guru, but this sounds inherently broken to me.

I think the right thing to do would be to do a redirect-after-post. ie, the login form posts to somewhere, which returns a 301 (or whatever) redirect back the original URL. The login form shouldn't POST back to the original URL.

I'm probably wrong though.

lbruno said...

I'd do the same, Peter.

But lets see this scenario: I've just POSTed a comment to a blog post, but I wasn't logged in. After successfully logging in, my initial POST handler should be done.

Does this even require an external redirect? My first attempt at this was to recreate (at the login form) the submitted information. But file-uploads don't work that way.

My idea: save all information needed (including temporary file uploads) and call our POST after successful authentication.

Steve said...

If you are going far enough to redirect the user back to their original page after login then ideal behavior would be for the login page to proxy the original request, be it a GET or a POST, and return the result as the output from the login submission.

Once the client gets involved it's going to get either POST redirects or GET redirects wrong, and both are potential application failures.

I've not come across a system that does that yet. ASP.Net lamely does a GET redirect, as do most other systems I've come across that bother to do anything.

Anonymous said...

That gives me an idea. A framework could store unauthenticated request in a session variable, redirect to a logon form, then replay the request afterwards. This way, for all intents and purpose everything is RESTful, plus the referer would reflect the original referer, not the logon form.

Popular Posts