Django Admin integation fix adding AuthToken

[paulgueltekin]

The current state of the Django Admin integration for adding new AuthToken is not really functional.

I created a custom admin form for adding new tokens, that requires to specify a user and optionally a expiry date.
To get the django form save() method to work, which does internaly not use the managers create() method, but creates a AuthToken object and later calls .save() i had to extract the logic for generating the digest and token values from the AuthTokenManager.create() method to reuse it in the admin form.

The Token itself will be presented to the user using the django messaging framework ( which is a requirement for the admin anyway) after saving the AuthToken ( see attached image )

I also added a search filter to the AdminView to filter the list of AuthTokens for User.USERNAME_FIELD, token_key and digest value.

Finally i added the admin view dependencies to to reference project.

[codecov]

Codecov Report

Attention: Patch coverage is 48.78049% with 21 lines in your changes are missing coverage. Please review.

Project coverage is 87.64%. Comparing base (271179a) to head (f6a77a3).

❗ Current head f6a77a3 differs from pull request most recent head 967d664. Consider uploading reports for the commit 967d664 to get more accurate results

Files	Patch %	Lines
knox/admin.py	43.75%	18 Missing ⚠️
knox/models.py	66.66%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #330      +/-   ##
===========================================
- Coverage    91.70%   87.64%   -4.07%     
===========================================
  Files            9        9              
  Lines          229      267      +38     
  Branches        35       40       +5     
===========================================
+ Hits           210      234      +24     
- Misses          16       30      +14     
  Partials         3        3              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[johnraz]

I don’t quite see the need for generating auth token in the admin like this… They should be generated by providing the user login/password combo.
I see several issues with this:

• anybody with access to the admin can now generate a token for any user, this might no be what you want
• this way of generating the token will encourage copy / pasting of the token by humans while I think it should be generated and propagated by machines only
• if you want a self service « token generator », I truly think it shouldn’t live in the admin at all
  Could you explain what is your use case here?

[paulgueltekin]

Thanks for your review and comments.

Regarding your comments:

1. This is currently also possible ( at least with the default configuration/settings ), but not in a user friendly way:

Anyone with access to the admin interface can currently add a token over the admin interface for any user, as its possible to enter the digest and a token_key. he just has to calulate the digest of the desired key manually

With default settings :

import hashlib
token = "0"*64   # or whatever key you want
digest = hashlib.sha512(bytes(token, 'utf-8')).hexdigest()
token_key = token[:15]
print(token_key, digest)
000000000000000 8f6beb3c0792f50c176800332f4468f76b4457b41d2f68e294cb46e53addbf5769a59eddf33e19394e8ab78e374b1bd33a680d26464fcd1174da226af9c8cd6e

But i dont see any problem here:
Admins ( users with is_admin flag ) should actually be able to do such operations ( they can active/deactivate accounts, changes passwords for users, delete tokens anyway .. )
Staff ( users with is_staff flag ) dont have any initial permission to add AuthToken keys, the need explicitly given the permission to add AuthToken keys.

Additional note: maybe this was the reason why there was a salt ( see #188 ) because with the salt this would not be possible, as the salt would be needed to calculate the digest.

2. That is exactly my use case, see 3)

3. My usecase ( and inspiration for creating this pull request ) is the following scenario:

I have some API endpoints that are not meant for regular users but for "system operations". To authorize the 3rd party software the admin should be able to create a Auth Token manually and provide to the 3rd party software. As the 3rd party software has no way to automatically upgrade the token on a refresh, it would basically a Token with no expiry.
So in my usecase i dont even have the knox API endpoints exposed.

Anyway, if you find this usecase scenario not relevant, and it was never meant to add AuthToken over the admin, i suggest hiding the "Add" button in the AuthToken admin. ( I can do the PR ) because its kinda missleading.

[johnraz]

@paulgueltekin Sorry took me a while to get back to this.

Thanks for clarifying and in the light of your last comment I am now more in favor of merging this in.

Can you look into the pre-commit errors maybe ?

[johnraz]

@giovannicimolin maybe you'd like to give this one a look as well?

[giovannicimolin]

@johnraz Thanks for the heads up! I'll try reviewing this tomorrow.