2011/3/14 Juan Pablo Martínez <jpm...@gmail.com>: > I dont think so. > If I dont know the username and password I > can also try username and password and wait for the system > to send another different error message. then I get valid credentials.
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 >From the AAA, Django currently only really provides Authentication (auth) and Access Controls (permissions). It doesn't really provide any mechanism for Authorization. In my projects, we have utilized _ExtendedCheckLogin (the class from which @login_required is built around in 1.2 IIRC) to provide @user_passes_test decorator, which takes a lambda function which is called with the current user, and @logged_in_permission_required, which is a specialization of @user_passes_test that simply takes a permission name. So, why am I jabbering about AAA, when this is about correctness of an error message on the admin site? Well, the two dovetail quite nicely. Imagine that django has this full AAA support. The admin views are no longer decorated with @login_required, since they require a lot more than that. Instead, they look something like this: @user_passes_test(lambda u: u.is_staff or u.is_superuser) def index(request): ... Now this whole argument is moot. If the logged in user does not have access to the admin site, they are sent to the homepage with a message explaining that they don't have access. If they aren't logged in, they get sent to the login page in order to do so. We now never have to confuse our users by showing a logged in user a login form. Now lets examine the extra information we may be leaking to an attacker: If the site has both admin login, and regular login, then there is no additional risk; an attacker detecting that a user account exists and that they have the right credentials for that user by detecting a change in error message from logging into a protected resource that the user does not have access to is no different than an attacker confirming an account exists and they have the right credentials by actually logging into the account in the main interface. If the site only has admin login, then the attacker would be able to determine that there is a user account with these credentials. However, this would be credentials for a user who cannot themselves log into the site, making them of limited usefulness. I hope this wasn't too long to read! Cheers Tom -- 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.
