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 [email protected].
To unsubscribe from this group, send email to
[email protected].
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
