On 30/05/2012 4:25am, phill wrote:
> I'm interested in inverting the diligence required to lock down URLs
> for my Django app. That is to say, today we put decorators that are
> some form of @login_required on view methods that require auth, and no
> decorators on views that are wide open. I'd like to invert that (or
> force decorators on both). I played around with things like having the
> decorators pin an attribute to the function and then use a bit of
> middleware to assert the attribute exists. It runs into issues though,
> when it comes to using third party views like auth_views, etc. In
> general, I'm worried it might be too fragile.
>
> I'm curious if anyone's familiar with a robust strategy for achieving
> this. Seemed like something that might be a common request for apps
> that do most of their work under auth
See
http://stackoverflow.com/questions/2164069/best-way-to-make-djangos-login-required-the-default
> .
>
> Thanks in advance,
> Phill
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/_Ilw1T03j7MJ.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment