Because django.auth.authenticate uses TypeErrors to check whether the backend has been called with the correct signature, there may not be an easy solution for this, but some options would include:

Check Exception.message for /takes (?:exactly \d+|no) arguments?/ and re-raise or logger.exception() if it doesn't match. This would significantly narrow down the cases where the wrong exception would silently pass. (A simpler, quicker check of "argument" in e.message would also work)

Change History (17)

I've got bitten by that recently. The ​django-openid-auth project changed a method signature in a recent release and it was raising a TypeError in my code causing the authenticate() to fail. If think the second option is the way to go since the first one is too fragile and won't work if a TypeError is raised in an invalid signature case.

Is there any particular reason backends can't signal "I cannot handle this signature" by returning None (as is already the case actually)?

Or, if we want to be fastidious about it, return some aptly named constant like contrib.auth.CannotHandle. Anything explicit instead of incidental will do really.

Existing backends would have to be updated. A planned deprecation could be introduced by initially accepting TypeError as before, but also issuing a deprecation nag/warning, and subsequently, re-raising TypeErrors from the same spot but with an added explanation that it's probably just your backend that needs to be updated.

Checking for a particular subtype of TypeError (i.e. argument signature mismatch specifically) simply narrows the number of real backend errors that can be masked, but IMO, it's still a reasonably common error...