I think that makes total sense. I guess I'm mulling over the best-fit-approach of using the available Pyramid exceptions, and wondering if it would be better to create more meaningful exceptions for the web app and then handle these by serving the best-fit-http-response. Say for example the 303 might be the best choice but I might be restricted to using 302 because of user agent support, but at the app level the exception remains accurate (e.g. raise AuthenticationRequired, or raise PermissionRequired, do stuff, serve most appropriate http response). I can't help thinking that trying to shoe horn http protocol into application exception logic is at the heart of the confusion the original poster is experiencing?
On 10 Feb 2012, at 18:58, Michael Merickel <[email protected]> wrote: > 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. -- 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.
