Hi all,
In messing around with the test Client recently, it occurred to me that there is some duplication in login schemes between contrib.admin and contrib.auth.
Is there any particular reason that contrib.admin doesn't use the login views and decorators provided by contrib.auth?
Both admin and auth provide login protection decorators. The decorator from auth is more generalized, but less attractive (requiring a redirect and GET data). The @staff_member_required decorator from admin is less generalized, but a much cleaner end user UI, IMHO (a transparent template swap on the decorated view).
The admin decorator could be generalized as a replacement for @user_passes_test, which would allow end users to use the same transparent login that admin uses. This would require end user changes to any login templates, but would allow the removal of login views. Alternatively, we could have both style of decorator in contrib.auth (although I'm not sure what to call the admin-style login_required or admin-style user_passes_test)
If nothing else, it looks like an example of Django not eating its own dogfood - we provide a login scheme, but don't use it in the one application that requires login protection.
Is this a refactor that is worthwhile? Or am I missing something obvious?
Your,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" 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-developers
-~----------~----~----~----~------~----~------~--~---
