Django Admin integation fix adding AuthToken

paulgueltekin commented 4 months ago

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[bot] commented 4 months ago

Codecov Report

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

Project coverage is 87.64%. Comparing base (271179a) to head (f6a77a3). Report is 14 commits behind head on develop.

:exclamation: Current head f6a77a3 differs from pull request most recent head 37f420b

Please upload reports for the commit 37f420b to get more accurate results.

Files	Patch %	Lines
knox/admin.py	43.75%	18 Missing :warning:
knox/models.py	66.66%	3 Missing :warning:

Additional details and impacted files

```diff @@ 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 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

johnraz commented 4 months ago

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 commented 4 months ago

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 https://github.com/jazzband/django-rest-knox/issues/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 commented 2 months ago

@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 commented 2 months ago

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

giovannicimolin commented 1 month ago

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

giovannicimolin commented 4 weeks ago

@johnraz Sorry for missing this here, spent a few days at the hospital and then things got hectic at my company and I had no time for this.

Reviewing it now.

giovannicimolin commented 4 weeks ago

@paulgueltekin @johnraz I think this is a reasonable change. I tested it locally and it's working nicely too! :rocket:

Can you perform the following steps before we move this forward:

Squash your commits to a single one
Fix failing linter issues

Thanks for the contribution!

paulgueltekin commented 3 weeks ago

Hi, i will check this today, thanks for your review

jazzband / django-rest-knox

Django Admin integation fix adding AuthToken #330

Codecov Report