Hi Simon, Actually, the code I posted does work, and I was just looking for a better solution.
If you read my reply to you: > I think I will just rename my view from "login" to "not_authorized", and make > the 403 response looks more conforming. that's essentially the same as what Michael suggested with the view named "forbidden_view" and the associated template "unauthorized.mako". I think the source of confusion is that the tutorial uses a view named "login" for the Forbidden context. Once the view is renamed to something like "not_authorized" or "forbidden_view", everything flows nicely. On Feb 11, 2:13 am, Simon Yarde <[email protected]> wrote: > 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 > > athttp://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.
