Reset password

API Views

There are two views used in the login workflow:

send-reset-password-link

rest_registration.api.views.send_reset_password_link(request, *args, **kwargs)

reset-password

rest_registration.api.views.reset_password(request, *args, **kwargs)

Assuming that the Django REST registration views are served at https://backend-host/api/v1/accounts/ then the send_reset_password_link, reset_password views are served as:

https://backend-host/api/v1/accounts/send-reset-password-link/
https://backend-host/api/v1/accounts/reset-password/

accordingly.

Verification workflow

Let’s describe it by example. We’re assuming that:

the Django REST Registration views are served at https://backend-host/api/v1/accounts/
you have ‘RESET_PASSWORD_VERIFICATION_ENABLED’ set to True (this by default)
you configured ‘RESET_PASSWORD_VERIFICATION_URL’ to be https://frontend-host/reset-password/

Then the verification workflow looks as follows:

The user who wants to reset his/her password sends AJAX POST request to https://backend-host/api/v1/accounts/send-reset-password-link/ endpoint. Usually this happens via front-end aplication, which could be hosted on https://frontend-host/.
Assuming the registration was correct, The send_reset_password_link endpoint will generate an e-mail which will contain an URL which the user should click to enter new password. the URL would be in a form:

https://frontend-host/reset-password/?user_id=<user id>&timestamp=<timestamp>&signature=<signature>

(You can change the way the URL is generated by overriding ‘VERIFICATION_URL_BUILDER’)
The frontend endpoint (which is not provided by Django REST Registration) https://frontend-host/reset-password/ would receive following GET parameters:
- user_id
- timestamp
- signature
and after obtaining the new password from the user it should perform AJAX request to https://backend-host/api/v1/accounts/reset-password/ via HTTP POST with following JSON payload:
```
{
    "password": "<new password>",
    "user_id": "<user id>",
    "timestamp": "<timestamp>",
    "signature": "<signature>"
}
```
and then show a message to the user depending on the response from backend server.

Default serializers

DefaultSendResetPasswordLinkSerializer

class rest_registration.api.serializers.DefaultSendResetPasswordLinkSerializer(*args, **kwargs)[source]

Default serializer used for sending reset password link.

It will use ‘SEND_RESET_PASSWORD_LINK_SERIALIZER_USE_EMAIL’ setting.

get_fields()[source]: Returns a dictionary of {field_name: field_instance}.

List of settings

These settings can be used to configure reset password workflow. You should add them as keys (with values) to your settings.REST_REGISTRATION dict.

‘SEND_RESET_PASSWORD_LINK_SERIALIZER_CLASS’

Default: 'rest_registration.api.serializers.DefaultSendResetPasswordLinkSerializer'

The serializer used by send-reset-password-link endpoint. You can use your custom serializer to customise validation logic and perform additonal checks. Please remember that it should implement get_user_or_none method which is used to obtain the user matching the criteria.

‘SEND_RESET_PASSWORD_LINK_USER_FINDER’

Default: 'rest_registration.utils.users.find_user_by_by_send_reset_password_link_data'

By default the user finder function will use ‘USER_LOGIN_FIELDS’ setting to extract the login field from the validated serializer data either by using the ‘login’ key or the specific login field name(s) (e.g. ‘username’, ‘email’). You can change that behavior by overriding this setting.

The user finder function receives these parameters as positional arguments:

data - the validated data from the send reset pasword link serializer.

and these parameters as keyword arguments:

serializer - the source send reset password link serializer which generated the input data. This parameter could be dropped in the future, so it should be retrieved via kwargs.get() instead be named directly.

If the user cannot be found, the function should raise UserNotFound exception (from rest_registration.exceptions).

‘SEND_RESET_PASSWORD_LINK_SERIALIZER_USE_EMAIL’

Default: False

Used specifically by DefaultSendResetPasswordLinkSerializer.

If True, use e-mail field instead of login fields to find the user who should receive the reset password link.

‘RESET_PASSWORD_FAIL_WHEN_USER_NOT_FOUND’

Default: True

If True, then reveal that the user does not exist while reset password link is being sent by signaling an error.

‘RESET_PASSWORD_VERIFICATION_ENABLED’

Default: True

No description available, please add it here!

‘RESET_PASSWORD_VERIFICATION_EMAIL_SENDER’

Default: 'rest_registration.verification_notifications.send_reset_password_verification_email_notification'

By default the email sender function will work with the build-in email sending mechanism.

You can handle email sending all by yourself by overriding this setting.

‘RESET_PASSWORD_VERIFICATION_PERIOD’

Default: datetime.timedelta(days=1)

No description available, please add it here!

‘RESET_PASSWORD_VERIFICATION_URL’

Default: None

No description available, please add it here!

‘RESET_PASSWORD_VERIFICATION_ONE_TIME_USE’

Default: False

No description available, please add it here!

‘RESET_PASSWORD_VERIFICATION_EMAIL_TEMPLATES’

Default:

{'body': 'rest_registration/reset_password/body.txt',
 'subject': 'rest_registration/reset_password/subject.txt'}

No description available, please add it here!

‘RESET_PASSWORD_SERIALIZER_PASSWORD_CONFIRM’

Default: False

Used by ResetPasswordSerializer. If True, the serializer requires additional field password_confirm which value should be the same as the value of password field.

It may be useful to disable it (this is currently the default) if you perform password confirmation at the frontend level.