Customize which user can login

[t-io]

For one of my projects, I want a user first to confirm their email before they can log in. For this, I use the package django-simple-email-confirmation which extends the user with a boolean is_confirmed. To achieve this behavior I have to either do some syncing with the build-in user.is_active or I have to overwrite TokenObtainSerializer.validate().

So what I would like to propose is a setting SIMPLE_JWT['user_login_rule'] = 'path.to.some.file.function' which returns a boolean and is called here in the TokenObtainSerializer.

This would also resolve the issue #137

If desired I could create a PR.

[Andrew-Chen-Wang]

Hi, I recommend against what that package does. I use django-allauth to have a separate model (which still has a unique index on the username) so that you can have something like an expiring mechanism for verification.

In that case, we wouldn’t need to have this extra validation measure. The purpose of this package is for already verified users as many Django projects do not even have an email verification method since it’s somewhat expensive.

[t-io]

Hey @Andrew-Chen-Wang,
I get your point regarding django-allauth. That is definitely a better approach for storing data.
But that aside I think it is valuable to have the who-can-authenticate with JWT flexible through optional configuration.
For example, if you want to implement a soft-delete, where the user is still there but not yet physically deleted. This can be completely independent of is_active. Alternatively, you could also have some blocked_since_timestamp.
My proposal does not add any extra validation measures, it only keeps the JWT auth flow flexible.

So the default still could be something like

def raise_jwt_allowance(user):
    return user is None or not user.is_active

But could easily be customized in the JWT settings with a path to some custom code which, for example also prohibits blocked users from authenticating.

SIMPLE_JWT['user_login_rule'] = 'path.to.some.file.custom_raise_jwt_allowance'

def custom_raise_jwt_allowance(user):
    return user is None or not user.is_active or bool(user.blocked_since_timestamp)

[Andrew-Chen-Wang]

@t-io I’d be happy to see a PR! Just make sure you add documentation and tests since @davesque is the main person here who can merge PRs. I’ll review it, too, once the pr’s out.

[Andrew-Chen-Wang]

@t-io Any updates on a fork? I'm not able to find how other libraries incorporate permission-based logins... would we need decorators? Custom decorators? I don't know, but lemme know on any progress!

[t-io]

Hey @Andrew-Chen-Wang, I prepared the feature and all existing tests are passing. I am still a bit uncertain where to put my code regarding the existing project structure. Please let me know what you think.
tests and documentation are still missing, I will pass them later.

link to feature commit

[Andrew-Chen-Wang]

@t-io Looks good! Like the callable too. I believe where it’s at currently is fine, but I’m just triage; however, in my opinion, it looks fine. Mind adding some documentation, too. Ping: @davesque

[Andrew-Chen-Wang]

@t-io Do you mind adding tests? It could speed up the process for merge.

[t-io]

Hey @Andrew-Chen-Wang I am a bit busy right now. But I will manage to take care of the documentation and tests next week.

[llorenspujol]

+1 for adding customizable login rules. In my personal usage most of the times not all users on the DB are to be able to do login by default. I've had always some kind of validation, like email verification or be part of some group/party, or require to be invited somewhere for other user, etc. Adding this rules extendable would make a lot of sense IMO.

[Andrew-Chen-Wang]

@t-io Do you mind creating a PR? I can focus on the docs, but it's a feature that is pretty good!

[llorenspujol]

I see that the related merge request has been accepted! good enhancement:) I accidentally found it: #279

Just for know, when is planned to publish a new version with those changes?

[Andrew-Chen-Wang]

I pinned an issue for v5.0.0. Once I find the time to incorporate Django 3.1 into the test cycle, we can publish it. I'm just looking to merge any other small features that might be necessary.