Hi, I understand the need for supporting multiple authentication systems, but I don't think that the implementation is the best that it can be done.
IMHO, silencing exceptions is something you should be very careful with even if you control all the code that you are doing it for. Other implementations will involve more work, yes. Whether that's worth doing it's not for me to decide. I would be inclined towards introducing the concept of Credentials of different types. Username/password would be one type, Token-based would be another one etc. The code that tries to authenticate will know what type of credentials it has (for example the login in admin knows that it has a username/password) so it can tell the authenticate() method the type of the Credentials. Authentication backends would be written for a given type of Credentials and shouldn't be called with other credential types. (Alternatively they could be called with Credential types they don't support, but will be required to raise an UnsupportedAuthenticationMethod exception. In this case the API would make it clear that your custom Authenticator can get different Credential types, so you have to handle the unsupported ones.) The current implementation assumes that TypeError can be raised only by the call to authenticate(**credentials) method (which isn't true) and also that it will always be raised if the wrong credentials are passed in. We already discussed the first assumption, but the second assumption is also wrong. For example if I have a Token based authenticator (authenticate(token)) that is configured to be after my User/Password based authenticator (authenticate(user, password)) in settings.py the current code will call the user/password based authenticator and it will pass in the token as a username (password will be null). If I have an authenticator with 2 string arguments, the same will happen. This is conceptually wrong and it could cause all kind of problems. For example my User/Password based LDAPAuthenticator might be making expensive LDAP queries as a result which will be much slower then a changed implementation. Regards, Tamas On Thu, Apr 23, 2009 at 8:06 AM, James Bennett <ubernost...@gmail.com> wrote: > > On Mon, Apr 20, 2009 at 4:20 AM, Tamas Szabo <szab...@gmail.com> wrote: >> As you can see the code catches and silently ignores all TypeError >> exceptions: >> The problems with this approach are: >> - Why not fail as early as possible if one of the authentication >> backends configured in settings.py has a wrong signature? If nothing >> else at least a warning should be logged IMHO. > > Because it's conceivable that you'll be using multiple authentication > systems on the same site, and that not all of them will expect the > same set of credentials. The alternative -- looking at the keys in the > 'credentials' dictionary and manually inspecting the argument > signature of the backend's method every time -- would be cumbersome, > slower and also error-prone (what happens when a backend accepts > '**kwargs' but really wants a specific set of keys in there and raises > a KeyError you didn't expect?) > >> - The bigger is that the code silently catches all TypeError >> exceptions. If the signature is correct, but the custom backend >> authenticator somewhere has a bug and a TypeError is raised as a >> result, the exception will be hidden away. TypeError is a common >> exception, so I don't think that catching and ignoring it in code that >> others will write is a good idea. > > People who write custom auth backends should probably be unit-testing > them independently of Django's auth framework, which would catch such > errors early on. And since Python doesn't offer a more specific > YouPassedArgumentsIDoNotLikeError, I think that means TypeError's the > way to go. > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
