Code

Opened 3 years ago

Closed 19 months ago

#15366 closed New feature (duplicate)

AuthenticationForm should optionally permit inactive user login

Reported by: krejcik@… Owned by: hjeffrey
Component: contrib.auth Version: 1.3-beta
Severity: Normal Keywords: inactive
Cc: hjeffrey Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

ModelBackend now allows login with inactive user (it has supports_inactive_user property).
But AuthenticationForm never allows login of such user.
I guess it should be configurable because it is designed as base form for all authetication forms.

Attachments (2)

15366.diff (1.4 KB) - added by hjeffrey 3 years ago.
15366-alternative.diff (973 bytes) - added by aaugustin 3 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 3 years ago by russellm

  • milestone 1.3 deleted
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 3 years ago by hjeffrey

  • Cc hjeffrey added
  • Owner changed from nobody to hjeffrey
  • Status changed from new to assigned

Changed 3 years ago by hjeffrey

comment:3 Changed 3 years ago by hjeffrey

  • Has patch set

comment:4 Changed 3 years ago by hjeffrey

  • Triage Stage changed from Accepted to Design decision needed

I don't know it this is the best way of handling the problem, but it seemed the simplest and most straight forward solution that would work generically.

There is possibly the issue that could arise were there are several backends for which the user has inactive accounts, some of which allow inactive users to log in while others do not. In this scenario the user would be rejected if the first backend that had credentials for him didn't allow inactive users to log in ever if others in the list did or even if he had an active account further down the list of backends.

Is inactive user login going to be a project wide setting for all backends or be handled on a backend by backend basis? If it's project wide the approach should work alright, but it still ignores active accounts further down in the list. If it's backend by backend what would be the appropriate authentication handling under the scenario presented?

Last edited 3 years ago by hjeffrey (previous) (diff)

comment:5 Changed 3 years ago by lrekucki

  • Severity set to Normal
  • Type set to New feature

comment:6 Changed 3 years ago by hvdklauw

#12103 is also about inactive users login

comment:7 Changed 3 years ago by aaugustin

  • Easy pickings unset
  • Needs documentation set
  • Needs tests set
  • Patch needs improvement set
  • Triage Stage changed from Design decision needed to Accepted
  • UI/UX unset

We must consider:

Currently, the best solution is to subclass AuthenticationForm and override clean entirely. I'm attaching a patch that makes it easier to support inactive users in a subclass. This would need a little bit more investigation (where is AuthenticationForm used? what do the docs say?), possibly a more complete patch, then tests and docs.

Changed 3 years ago by aaugustin

comment:8 Changed 19 months ago by claudep

  • Resolution set to duplicate
  • Status changed from assigned to closed

For me, #12103 is actually a duplicate with a much more elaborate patch (including tests and docs).

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.