Registration
API Views
There are two views used in the registration workflow:
register
- rest_registration.api.views.register(request, *args, **kwargs)
verify-registration
- rest_registration.api.views.verify_registration(request, *args, **kwargs)
Assuming that the Django REST registration views are served at
https://backend-host/api/v1/accounts/
then the register
, verify_registration
views are served as:
https://backend-host/api/v1/accounts/register/
https://backend-host/api/v1/accounts/verify-registration/
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 ‘REGISTER_VERIFICATION_ENABLED’ set to
True
(this by default)you configured ‘REGISTER_VERIFICATION_URL’ to be
https://frontend-host/verify-user/
Then the verification workflow looks as follows:
The user who wants to register itself sends AJAX POST request to
https://backend-host/api/v1/accounts/register/
endpoint. Usually this happens via front-end aplication, which could be hosted onhttps://frontend-host/
.Assuming the registration was correct, The
register
endpoint will generate an e-mail which will contain an URL which the newly registered user should click to activate his/her account. the URL would be in a form:https://frontend-host/verify-user/?user_id=<user id>×tamp=<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/verify-user/
would receive following GET parameters:user_id
timestamp
signature
and then it should perform AJAX request to
https://backend-host/api/v1/accounts/verify-registration/
via HTTP POST with following JSON payload:{ "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
DefaultRegisterUserSerializer
- class rest_registration.api.serializers.DefaultRegisterUserSerializer(*args, **kwargs)[source]
Default serializer used for user registration. It will use these:
User fields
‘USER_HIDDEN_FIELDS’ setting
‘USER_PUBLIC_FIELDS’ setting
to automagically generate the required serializer fields.
Signals
There are many cases where only a small bit of additional logic needs to be injected into the registration process, and writing a custom workflow to support this represents an unnecessary amount of work. A more lightweight customization option is provided through two custom signals which the built-in registration workflows send, and custom workflows are encouraged to send, at specific points during the registration process; functions listening for these signals can then add whatever logic is needed.
For general documentation on signals and the Django dispatcher, consult Django’s signals documentation. This documentation assumes that you are familiar with how signals work and the process of writing and connecting functions which will listen for signals.
- user_activated
Sent when a user account is activated (not applicable to all workflows). Provides the following arguments:
- sender
None - No class is sending this signal
- user
A user-model instance representing the activated account.
- request
The Request in which the account was activated.
This signal is automatically sent for you by the base
register()
, so unless you’ve overridden it you should not need to explicitly send it.
List of settings
These settings can be used to configure registration workflow.
You should add them as keys (with values)
to your settings.REST_REGISTRATION
dict.
‘REGISTER_FLOW_ENABLED’
Default:
True
If enabled, then users are able to register (create new account).
One can disable it if for instance accounts should not be registered by external users but rather should be created only by admin user.
‘REGISTER_SERIALIZER_CLASS’
Default:
'rest_registration.api.serializers.DefaultRegisterUserSerializer'
The serializer used by register endpoint. It is used to validate the input data and save (create) the newly registered user. You can use your custom serializer to customise validation logic and the way the user is created in the database.
‘REGISTER_SERIALIZER_PASSWORD_CONFIRM’
Default:
True
Used by DefaultRegisterUserSerializer
.
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 if you perform password confirmation at the frontend level.
‘REGISTER_OUTPUT_SERIALIZER_CLASS’
Default:
'rest_registration.api.serializers.DefaultUserProfileSerializer'
The default serializer used by register endpoint. It is used output the data associated with the newly registered user. You can use your custom serializer to customise the output representation of the user.
‘REGISTER_VERIFICATION_ENABLED’
Default:
True
If enabled, then newly registered user will not
be verified (user field specified by
‘USER_VERIFICATION_FLAG_FIELD’ will be false),
and verification e-mail with activation link
will be sent to the user email (specified by USER_EMAIL_FIELD
).
‘REGISTER_VERIFICATION_EMAIL_SENDER’
Default:
'rest_registration.verification_notifications.send_register_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.
‘REGISTER_VERIFICATION_PERIOD’
Default:
datetime.timedelta(days=7)
Specifies how long the activation link will be valid.
‘REGISTER_VERIFICATION_URL’
Default:
None
Frontend URL to which the query parameters will be appended to create the activation link for newly registered user.
‘REGISTER_VERIFICATION_ONE_TIME_USE’
Default:
False
No description available, please add it here!
‘REGISTER_VERIFICATION_EMAIL_TEMPLATES’
Default:
{'body': 'rest_registration/register/body.txt',
'subject': 'rest_registration/register/subject.txt'}
Directory of templates used to generate the verification email. There are separate templates for email body and subject. If you want to generate html emails please refer to HTML e-mail configuration.
‘REGISTER_VERIFICATION_AUTO_LOGIN’
Default:
False
Specifies whether a user will be logged in automatically when they verify their registration.