use only authenticate for create token #819
Conversation
tomwojcik
changed the title
|
@hisie this approach would work for you as well, right? |
There was a problem hiding this comment.
Overall it looks good and pretty simple.
However, this PR questions the existence of LOGIN_FIELD setting in djoser at all. It only gives consent through silence to define your model auth backend based on LOGIN_FIELD. Yet, this silence maybe misleading with the current documentation:
LOGIN_FIELD
Name of a field in User model to be used as login field. This is useful if you want to change the login field from username to email without providing custom User model.
In fact, to make it really working (your tests are just mocking it), you need to define either custom User model OR custom auth backend.
That is why I like @hisie approach in #810 that provides custom auth backend ready to use. Thanks to that you can easily say in the documentation: "Don't you have custom user model? Then use LOGIN_FIELD setting and this custom auth backend."
If for some reason we do not want to provide custom auth backend then we should do both:
- give more info in the docs on how to create custom auth backend with example code
- make bold statement in the documentation that custom auth backend is just workaround and the proper way of doing this is to have custom user model with USERNAME_FIELD redefined.
Thoughts?
| ) | ||
| @override_settings( | ||
| DJOSER=dict(django_settings.DJOSER, **{"LOGIN_FIELD": "username"}) | ||
| ) |
There was a problem hiding this comment.
I would merge decorators for better readability. It's easy to get confused or just skip one of the override_settings calls. The same applies to tests below this one.
|
Sorry for the delay. As @haxoza says, my proposal of testing with djoser_settings.LOGIN_FIELD was intended to easily keep backwards compatibility with the old behaviour. I don't like the old behaviour at all because it hides custom auth backend authentications, but I can understand that migrating from a running project using djoser LOGIN_FIELD to a custom user with an auth backend should be hard. Both solutions (@tomwojcik and mine) are good for me since both avoid giving tokens to users who don't match existing authentications. While not being responsible of the project, I let you decide if you want to keep easily backwards compatibility or not. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #819 +/- ##
==========================================
+ Coverage 99.03% 99.05% +0.01%
==========================================
Files 26 27 +1
Lines 833 846 +13
==========================================
+ Hits 825 838 +13
Misses 8 8 ☔ View full report in Codecov by Sentry. |
| [ | ||
| ("username", "username", "username"), | ||
| ("email", "email", "email"), | ||
| ("email", "username", "email"), |
There was a problem hiding this comment.
backwards compat with LoginFieldBackend
There was a problem hiding this comment.
I'm sorry for a long delay in reviewing this PR.
@tomwojcik thank you, it looks great! I agree with this approach.
|
|
||
| If you don't want to roll out your own authentication backend, ``LoginFieldBackend`` has been prepared. | ||
| It works the same as ``ModelBackend``, but it is using ``LOGIN_FIELD`` instead of ``User.USERNAME_FIELD``. | ||
|
|
There was a problem hiding this comment.
| To make your code backward compatible with previous Djoser versions, add this auth backend to your Django settings: | |
| .. code-block:: python | |
| AUTHENTICATION_BACKENDS = [ | |
| "djoser.auth_backends.LoginFieldBackend", | |
| ] | |
| Please notice that it is not recommended way of authentication and it may be removed in the future Djoser versions. |
|
Good work. I can't wait to see released. Thank you very much. |
Closes #795
rollback 8f65bff
TBD drop Djoser LOGIN_FIELD in favor of Django's User USERNAME_FIELD