use only authenticate for create token

[tomwojcik]

Closes #795

rollback 8f65bff

TBD drop Djoser LOGIN_FIELD in favor of Django's User USERNAME_FIELD

[tomwojcik]

@hisie this approach would work for you as well, right?

[haxoza]

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:

1. give more info in the docs on how to create custom auth backend with example code
2. 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?

[haxoza]

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.

[tomwojcik]

95ae2a7

[hisie]

Sorry for the delay.
Yes I like this solution @tomwojcik .

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]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.05%. Comparing base (35c815f) to head (bd23a35).
Report is 15 commits behind head on master.

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.
📢 Have feedback on the report? Share it here.

[tomwojcik]

@hisie @haxoza I think that the previous approach had a vulnerability on Djoser side and the default behavior should change. I added an optional Model backend, (similar to your solution @hisie ), if someone wants backwards compat. Please let me know what you think. I believe it's ready to go as-is.

[tomwojcik]

backwards compat with LoginFieldBackend

[haxoza]

I'm sorry for a long delay in reviewing this PR.

@tomwojcik thank you, it looks great! I agree with this approach.

[hisie]

Good work. I can't wait to see released. Thank you very much.