Removing friction when extending django-rest-knox

[lalvarezguillen]

Hi. Fantastic job on this project!

At work django-rest-knox has become a bit of a standard. I don't remember a project where we don't use django-rest-knox. In some projects we've experienced some friction when extending/customizing django-rest-knox, and it comes from 2 places mainly:

1. views.LoginView.post and auth.TokenAuthentication.authenticate_credentials reference AuthToken directly.

So if you want to use a different auth token model you're forced to overwrite those methods entirely.

This could easily be sorted out by adding a model property to LoginView and TokenAuthentication, which allows you to configure the auth token model. TokenAuthentication already have such property, it just doesn't make use of it everywhere.

2. When subclassing AuthToken, Django produces a one-to-one relationship between AuthToken and your custom subclass.

Which means that user.auth_token_set references a queryset of AuthTokens, instead of a queryset of your custom subclass; because the user-token relationship is inherited from AuthToken.

Also easy to solve, by moving the definition of AuthToken to an abstract AbstractAuthToken model, and having AuthToken inherit from it.

I'm proposing those changes in this MR: #252

I realize that a similar problem was brought up before (#159), and a more ambitious solution was attempted there. The changes I'm proposing are in the same vein, but not as ambitions. I don't think they prevent us from continuing on the more ambitious road in the future. They also don't break the current API at all.

Please let me know what you think.