Inverting URL security diligence - suggestions?

[phill]

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.

Thanks in advance,

Phill

[Marcin Tustin]

At the end of your views.py, have a piece of code that iterates through the keys in the local namespace, testing which are functions and applying your decorator. 

This will make it inconvenient to have utilities defined there, and it will make it inconvenient to import individual functions (instead you'll have to import their package, and access them through that). You could handle that by having an exclusion list, though. 

An alternative would be to put that in your urls.py (or import that into your views file), and go through the data there to identify actual view functions/objects.

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

--
Marcin Tustin
Tel: 07773 787 105

[Mike Dewhirst]

See
http://stackoverflow.com/questions/2164069/best-way-to-make-djangos-login-required-the-default


> .

[Kurtis Mullins]

If you tend to use the standard Class Based Views, you could always
add a mixin for that functionality. Or just start subclassing to make
it even easier to read (e.g. AuthenticatedUpdateView,
AuthenticateCreateView, etc...)