Just discovered that context.result in the forbidden view will be an ACLDenied object. I might be able to work with that. I'll played around with it and report back.
On Tue Jan 13 2015 at 9:09:12 AM Theron Luhn <[email protected]> wrote: > I already know how to set up the authentication and authorization—That's > no problem. What I don't know how to do is take the correct behavior when > access is denied. AFAIK in the Forbidden view there's no context as to why > access to the resource is forbidden. I don't want to ask a user to verify > their password if access will be denied to the requested resource > regardless of whether they're verified or not. > > > > On Tue Jan 13 2015 at 5:37:55 AM Arndt Droullier <[email protected]> wrote: > >> Handling redirects in case security checks fail is quite easy. For eample >> the following will set up >> a redirect: >> >> #------------------------------------------------------------ >> from pyramid.exceptions import Forbidden >> from pyramid.httpexceptions import HTTPFound >> >> def forbidden_view(forbiddenResponse, request): >> return HTTPFound(location='loginform') >> >> def main(): >> # pyramid view configuration >> config.add_view(forbidden_view, context=Forbidden) >> #------------------------------------------------------------ >> >> Passwort verification itself is not part of pyramids api. It is handled >> by your user management. >> At least pyramids default AuthTktAuthenticationPolicy and >> ACLAuthorizationPolicy has nothing >> to do with passwords. >> The password should be validated before you call remember. >> >> After that to check user authentication you can use >> >> request.authenticated_userid >> >> and >> >> request.unauthenticated_userid >> >> The second will give you the username even if the user session (stored in >> a cookie for example) >> has expired. >> >> Hope this helps, Arndt. >> >> >> 2015-01-13 13:31 GMT+01:00 Tom Lazar <[email protected]>: >> >>> just as a general guide line i would always try to implement as much as >>> possible via roles and permissions. >>> >>> in this case i would suggest a role of perhaps Authenticated, Verified >>> and Anyonmous and then assign permissions to the views as your business >>> logic seems fit. >>> >>> this reduces the problem scope to assigning the Verified role, perhaps >>> in a custom callback. >>> >>> just a quick thought, hope it helps. >>> >>> cheers, >>> >>> tom >>> >>> On 12 Jan 2015, at 22:33, Theron Luhn <[email protected]> wrote: >>> >>> I'm working on authorization+authentication for my webapp. The login >>> has a "remember" feature so users don't have to log in each visit. As best >>> practice, any sensitive features (password changing, user management, >>> billing, etc.) should require a user to verify their password before >>> continuing. That way a malicious individual couldn't wreak too much havoc >>> if a user clicks "remember me" on a public terminal, for example. >>> >>> I'm trying to figure out a way to implement this with Pyramid's >>> authentication+authorization mechanisms. A simple custom authentication >>> policy is sufficient to declare a user as "verified" or "unverified", and >>> the ACL authorization policy can limit access to the sensitive features to >>> verified users. However, I can't figure out how to take the appropriate >>> action when access is denied. Depending on the state of the session, I >>> need to do one of three things: >>> >>> - No authenticated session — Redirect user to login form >>> - "Unverified" session and attempting to access sensitive feature — >>> Redirect user to verify password form >>> - Everything else — Show a 403 Forbidden error page. >>> >>> Any ideas on how I could achieve this? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "pylons-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/pylons-discuss. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "pylons-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/pylons-discuss. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> Nive open source releases - http://os.nive.co >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "pylons-discuss" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/ >> topic/pylons-discuss/h9k__SG-qbA/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/pylons-discuss. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
