dj-rest-auth: UID for password reset incorrectly uses base64

When a password reset link is request, the UID is encoded into the url as such, by django allauth

/accounts/password/reset/key/7w-1x7-d1a11z1sa1s1a1s/

Such that the uid is 7w and the token is 1x7-d1a11z1sa1s1a1s

The UID is encoded here, as base36: https://github.com/pennersr/django-allauth/blob/330bf899dd77046fd0510221f3c12e69eb2bc64d/allauth/account/forms.py#L524

However, when the UID decoded in django-rest-auth as base64 https://github.com/jazzband/dj-rest-auth/blob/02c9242e3d069164692ef44a0f15eaca31a41cac/dj_rest_auth/serializers.py#L214

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 15 (6 by maintainers)

Most upvoted comments

@iMerica Would you accept a patch that enforces the Django encoding of the UID instead of only checking for weather or not allauth is installed?

@iMerica should this actually be a setting, and not just based on whether allauth is installed? In our use case, we have allauth installed but not used to generate the UID/token for password resets (we’re using the default dj-rest-auth functionality which relies on PasswordResetForm which is in Django core). Surely having allauth installed doesn’t necessarily dictate that it will be used for password reset purposes?

(One could also certainly imagine an errant and unused installation of allauth in your environment, eg in a dependency, which would alter the above decoding functionality.)

Could this instead be a setting (called something like REST_USE_ALLAUTH_UID_DECODER) that allows you to concretely specify which decoder to use?

(The result for us it that we cannot use dj-rest-auth v2.1.6 onwards.)

When a password reset link is request, the UID is encoded into the url as such, by django allauth

password-reset/confirm/NDc/5m9-db35d6f0efc16645b352/

Here UID is NDc And token is 5m9-db35d6f0efc16645b352