The admin is not "one more app" is (if I may) the app with more weight on most sites. Someone who has access to the admin has access to most or all information. There is no "one more app. "
Carelessness or neglect of a click in the admin should't call into question the admin with the justification "that does not happen again." If the application is used only in Intranet or not is entirely separate from whether to put the right message or not. I think if everyone is going to fix "contrib" to your needs the contrib lost all independence. 1.3 will create a special form and then you can change the message. I do not think the amendment is necessary. Regards, On 14/03/2011, Nick Phillips <nick.phill...@otago.ac.nz> wrote: > On Mon, 2011-03-14 at 15:57 +0000, Tom Evans wrote: > >> This is one of my bug-bears with the current authentication system - >> it has no concept of role. The current action when an identified user >> visits the admin site is to display a login form, which is totally >> wrong in my opinion. The user has already presented credentials, which >> we have accepted, so why should we expect them to have another >> different set of credentials? >> >> Similarly, most restricted access views are currently protected by the >> login_required decorator. Again, this is pretty good, but it doesn't >> solve the authorization issue. With the vast majority of views I >> decorate with @login_required, I actually need three states: >> >> Unidentified -> login page >> Identified, but no access -> homepage, with error message >> Identified, access -> allow through > > Spot on, IMO - it's muddling authentication and authorization up > together. The user is authenticated, and shouldn't be arbitrarily given > the impression that they're not when they try to access a page to which > they don't have access. There's nothing "special" about the admin here, > except that it is provided as part of the "batteries included". How does > your site respond when a user tried to access any other URL to which > they are denied access? Whatever happens there is probably what should > happen when they try to access the admin. It could be a 403, a redirect > to homepage, a forced logout with disabling of account and email to > admin, could be all sorts of things, depending on the site. > > The question should probably be "how can we allow the developer to > specify the desired behaviour when the user attempts to access a URL to > which they have no access?" - subject to the usual provision of sensible > defaults etc. > > > Cheers, > > > Nick > -- > Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz > # these statements are my own, not those of the University of Otago > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- :: juanpex -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
