On Fri, Feb 10, 2012 at 11:24 AM, Simon Yarde <[email protected]> wrote:
> I might have come at it differently raising 401 initially (all we can say > is 'auth required' because we don't know who the user is) and then issue > 403 if the authenticated user lacked a particular permission, but then I > probably haven't spent as much time wrestling with this matter - I would be > intrigued to learn of the reasoning if you have the time Michael? :) > The issue, as I see it, is that 401 should not be raised unless you have a custom authentication policy (and system) that explicitly supports returning a WWW-Authenticate header to challenge the browser, and then accepting the response. For example, for a Basic policy: Server: return the challenge in your forbidden view. Client: enter username/password into the popup box, submitting a new request for the same content, but with credentials in the header. Server: receive credentials as part of the request, and your authentication policy would see those credentials, and allow access to the content. If you don't have this type of mechanism in place, 401 doesn't make sense. I'd be happy to be corrected. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
