login_required does not check User.is_active

[Matt Dennewitz <mattdennewitz@…>]

The login_required decorator is not checking User.is_active, as staff_member_required does. If an authenticated user is deactivated (via setting is_active to False), the user is still able to browse login_required-protected views.

[Matt Dennewitz <mattdennewitz@…>]

Add "is_active" check to login_required

[Russell Keith-Magee]

It's an edge case, but one worth catching.

There is an edge case that the proposed patch doesn't catch - the case of a custom user object (from a custom auth backend) that doesn't provide is_active (since auth backends aren't required to provide it). Changing the simple 'user.is_active' check to 'getattr(user, 'is_active', True)' should provide a backwards compatible solution.

Patch also requires tests.

[Ramiro Morales]

See #7011 (and its related [9176] commit) for some info about why this is currently like it is. Also, #12113 (and [12193]) introduced further refinements in the related documentation.

[Russell Keith-Magee]

Thanks for the historical pointers ramiro. Thinking about this a bit more, there are some edge cases that require some additional consideration. ​Discussion on django-dev

[anonymous]

This should be changed, fast! It's a silly design decision!

[wim@…]

Ticket 13125 patch using getattr

[Jacob]

See ramiro's comments above. is_active is a hook for custom auth sources and custom auth logic; the built-in stuff doesn't check it. Yes it's a bit counter-intuitive, but changing it is going to break a number of expectations in users' code, so it's going to need to stay as is.