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?
Subscribe to:
Post Comments (Atom)
Popular Posts
-
These are the robots I've been working on for the last 12 months. They each weigh about 11 tonnes and have a 17 meter reach. The control... -
This hard-to-see screenshot is a Generic Node Graph Editing framework I'm building. I'm hoping it can be used for any kind of node... -
So, you've created a car prefab using WheelCollider components, and now you can apply a motorTorque to make the whole thing move along. ... -
MiddleMan: A Pub/Sub and Request/Response server in Go. This is my first Go project. It is a rewrite of an existing Python server, based o...
-
Why would I ask that question? Python 3 has been available for some time now, yet uptake is slow. There aren't a whole lot of packages i...
-
It is about 8 degrees C this morning. So cold, especially when last week we had high twenties. To help solve the problem, a friend suggeste...
-
After my last post, I decided to benchmark the scaling properties of Stackless, Kamaelia, Fibra using the same hackysack algorithm. Left axi... -
I'm now using bzr instead of svn. I'm pushing my repositories to: http://exactlysimilar.org/bzr/ I'm also auto publishing docume...
-
I've just read a newspaper article (courtesy of Kranzky ) from WA Business News documenting the malfeasance, gross negligence and misc...
-
Possibly slightly more correct lighting. The rim light is now only applied in the direction of the sun, rather than being purely based on vi...
4 comments:
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.
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.
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.
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.
Post a Comment