List of all settings

Below are listed all possible Django REST Registration settings. You should add them as keys (with values) to your settings.REST_REGISTRATION dict.

‘USER_LOGIN_FIELDS’

Type: typing.Optional[typing.List[str]]
Default: None

Setting that defines the list of fields which can be treated as “login” fields. An example of such fields would be username, email.

If not set / set to None, it will fall back to one-element list containing user_class.USERNAME_FIELD,

This setting is used by default ‘LOGIN_AUTHENTICATOR’ implementation and default ‘SEND_RESET_PASSWORD_LINK_USER_FINDER’ implementation.

To ensure integrity, Django-REST-Registration will check if each of the listed fields is unique. If you want to disable that check, please refer to ‘USER_LOGIN_FIELDS_UNIQUE_CHECK_ENABLED’.

‘USER_HIDDEN_FIELDS’

Default:

('last_login',
 'is_active',
 'is_staff',
 'is_superuser',
 'user_permissions',
 'groups',
 'date_joined')

No description available, please add it here!

‘USER_PUBLIC_FIELDS’

Default: None

No description available, please add it here!

‘USER_EDITABLE_FIELDS’

Default: None

No description available, please add it here!

‘USER_EMAIL_FIELD’

Default: 'email'

No description available, please add it here!

‘USER_VERIFICATION_ID_FIELD’

Default: 'pk'

Field used in verification, as part of signed data.

The given field should uniquely identify the user. This means that using any user field which could change over time (email, username) is NOT recommended.

‘USER_VERIFICATION_FLAG_FIELD’

Default: 'is_active'

No description available, please add it here!

‘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.

‘LOGIN_AUTHENTICATOR’

Default: 'rest_registration.utils.users.authenticate_by_login_data'

By default the login authenticator 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’). Then, it uses django.contrib.auth.authenticate() to find a matching user.

You can change that behavior by overriding this setting.

The authenticator function receives these parameters as positional arguments:

data - the validated data from the login serializer.

and these parameters as keyword arguments:

serializer - the source login 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).

If the user can be found, it should be returned. The implementer should ensure that the right authentication backend (if it was used to find a match) is provided as backend attribute of the returned user.

‘LOGIN_RETRIEVE_TOKEN’

Default: None

When set to True, the login view will returns the token.

To make sure that the token can be returned, rest_framework.authtoken must be added to the INSTALLED_APPS in your settings.

After added rest_framework.authtoken to the INSTALLED_APPS, you need to run python manage.py migrate to apply changes.

To use the token authentication, you have two options:

add rest_framework.authtoken.authentication.TokenAuthentication to the DEFAULT_AUTHENTICATION_CLASSES in your settings.

or set authentication_classes = [TokenAuthentication] in your view.

example 1:

REST_FRAMEWORK = {
    # ...
    "DEFAULT_AUTHENTICATION_CLASSES": [
        "rest_framework.authentication.TokenAuthentication",
        # ...
    ],
}

example 2:

from rest_framework.authentication import TokenAuthentication

class SomeAwesomeView(APIView):
    authentication_classes = [TokenAuthentication]
    # ...

Then you can get token from the login response:

{
    "detail": "Login successful",
    "token": "18eb5c64d21fcc6219facdcd05016d277f92cd90"
}

When you send a request to the protected view, you need to add the token to the request header:

Authorization: Token ${YourToken}

‘AUTH_TOKEN_MANAGER_CLASS’

Default: 'rest_registration.auth_token_managers.RestFrameworkAuthTokenManager'

The token manager class used by login and logout which provides an interface for providing and optionally revoking the token. The class should inherit from rest_registration.token_managers.AbstractTokenManager.

‘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.

‘REGISTER_EMAIL_SERIALIZER_CLASS’

Default: 'rest_registration.api.serializers.DefaultRegisterEmailSerializer'

The serializer used by register-email endpoint. It is used to validate the input data and obtain new e-mail. You can use your custom serializer to customise validation logic. The important part is that it should contain email field.

‘REGISTER_EMAIL_VERIFICATION_ENABLED’

Default: True

No description available, please add it here!

‘REGISTER_EMAIL_VERIFICATION_EMAIL_SENDER’

Default: 'rest_registration.verification_notifications.send_register_email_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_EMAIL_VERIFICATION_PERIOD’

Default: datetime.timedelta(days=7)

No description available, please add it here!

‘REGISTER_EMAIL_VERIFICATION_URL’

Default: None

No description available, please add it here!

‘REGISTER_EMAIL_VERIFICATION_EMAIL_TEMPLATES’

Default:

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

No description available, please add it here!

‘VERIFICATION_FROM_EMAIL’

Default: None

No description available, please add it here!

‘VERIFICATION_REPLY_TO_EMAIL’

Default: None

No description available, please add it here!

‘VERIFICATION_EMAIL_HTML_TO_TEXT_CONVERTER’

Default: 'rest_registration.utils.html.convert_html_to_text_preserving_urls'

No description available, please add it here!

‘VERIFICATION_URL_BUILDER’

Default: 'rest_registration.utils.verification.build_default_verification_url'

The builder function receives the signer object and construct the url using signer.get_base_url() and signer.get_signed_data(). The default url builder will use the base url and append the signed data as HTTP GET query string. It is be solely up to the implementer of custom builder function to encode the signed values properly in the URL.

‘VERIFICATION_TEMPLATE_CONTEXT_BUILDER’

Default: 'rest_registration.utils.verification.build_default_template_context'

The builder function receives these parameters as positional arguments:

user - the user which is to be notified.
user_address - the user address, which can be the user e-mail, phone number, etc.
data - dictionary; in most cases it contains only one entry, which is the param_signer under 'param_signer' key. The implementer of the custom builder function should be aware that the contents of the dictionary are dynamic and write defensive code to account that.

and these parameters as keyword arguments:

notification_type - value of rest_registration.notifications.enums.NotificationType enum.
notification_method - value of rest_registration.notifications.enums.NotificationMethod enum. Currently there is only one choice which is NotificationMethod.EMAIL.

It is possible that in the future, additional keyword arguments may be added. Therefore the implementer of the custom builder function should take account of that, for instance by adding **kwargs in the signature of the function.

‘VERIFICATION_TEMPLATE_RENDERER’

Default: 'rest_registration.utils.verification.default_render_template'

The builder function receives these parameters as positional arguments:

template_config_data - dictionary; data is populated by function set with ‘VERIFICATION_TEMPLATES_SELECTOR’ setting.
context - dictionary; data is populated by function set with ‘VERIFICATION_TEMPLATE_CONTEXT_BUILDER’ setting.

Function should return an instance of rest_registration.utils.verification.EmailTemplateRenderResult

It is possible that in the future, additional keyword arguments may be added. Therefore the implementer of the custom builder function should take account of that, for instance by adding **kwargs in the signature of the function.

‘VERIFICATION_TEMPLATES_SELECTOR’

Default: 'rest_registration.utils.verification.select_default_templates'

By default, the verification templates selector function will use templates defined by these settings:

‘REGISTER_VERIFICATION_EMAIL_TEMPLATES’
‘REGISTER_EMAIL_VERIFICATION_EMAIL_TEMPLATES’
‘RESET_PASSWORD_VERIFICATION_EMAIL_TEMPLATES’

depending on the notification type (register, registere email, reset password). You can change that behavior by overriding this setting.

The verification template selector function receives these parameters as keyword arguments:

request - the request which is source of sending given verification.
user - the user which is to be notified.
notification_type - value of rest_registration.notifications.enums.NotificationType enum.
notification_method - value of rest_registration.notifications.enums.NotificationMethod

It is possible that in the future, additional keyword arguments may be added. Therefore the implementer of the custom selector function should take account of that, for instance by adding **kwargs in the signature of the function.

The verification template selector should raise VerificationTemplatesNotFound exception when no matching templates were found. In that case, Django REST Registration will fall back to the default behavior (described above).

‘CHANGE_PASSWORD_SERIALIZER_PASSWORD_CONFIRM’

Default: True

No description available, please add it here!

‘PROFILE_SERIALIZER_CLASS’

Default: 'rest_registration.api.serializers.DefaultUserProfileSerializer'

No description available, please add it here!

‘SUCCESS_RESPONSE_BUILDER’

Default: 'rest_registration.utils.responses.build_default_success_response'

No description available, please add it here!

‘USE_NON_FIELD_ERRORS_KEY_FROM_DRF_SETTINGS’

Default: False

If True, the base API exception class will wrap the detail string message (or message list) into a dictionary with a key defined by REST_FRAMEWORK['NON_FIELD_ERRORS_KEY'].

‘NOT_AUTHENTICATED_PERMISSION_CLASSES’

Default: ['rest_framework.permissions.AllowAny']

This parameter establishes the permissions of the views that must be accessible without logging in. Basically replace AllowAny with the specified class.

List of all settings

‘USER_LOGIN_FIELDS’

‘USER_LOGIN_FIELDS_UNIQUE_CHECK_ENABLED’

‘USER_HIDDEN_FIELDS’

‘USER_PUBLIC_FIELDS’

‘USER_EDITABLE_FIELDS’

‘USER_EMAIL_FIELD’

‘USER_VERIFICATION_ID_FIELD’

‘USER_VERIFICATION_FLAG_FIELD’

‘REGISTER_FLOW_ENABLED’

‘REGISTER_SERIALIZER_CLASS’

‘REGISTER_SERIALIZER_PASSWORD_CONFIRM’

‘REGISTER_OUTPUT_SERIALIZER_CLASS’

‘REGISTER_VERIFICATION_ENABLED’

‘REGISTER_VERIFICATION_EMAIL_SENDER’

‘REGISTER_VERIFICATION_PERIOD’

‘REGISTER_VERIFICATION_URL’

‘REGISTER_VERIFICATION_ONE_TIME_USE’

‘REGISTER_VERIFICATION_EMAIL_TEMPLATES’

‘REGISTER_VERIFICATION_AUTO_LOGIN’

‘LOGIN_SERIALIZER_CLASS’

‘LOGIN_AUTHENTICATOR’

‘LOGIN_AUTHENTICATE_SESSION’

‘LOGIN_RETRIEVE_TOKEN’

‘AUTH_TOKEN_MANAGER_CLASS’

‘LOGIN_DEFAULT_SESSION_AUTHENTICATION_BACKEND’

‘SEND_RESET_PASSWORD_LINK_SERIALIZER_CLASS’

‘SEND_RESET_PASSWORD_LINK_USER_FINDER’

‘SEND_RESET_PASSWORD_LINK_SERIALIZER_USE_EMAIL’

‘RESET_PASSWORD_FAIL_WHEN_USER_NOT_FOUND’

‘RESET_PASSWORD_VERIFICATION_ENABLED’

‘RESET_PASSWORD_VERIFICATION_EMAIL_SENDER’

‘RESET_PASSWORD_VERIFICATION_PERIOD’

‘RESET_PASSWORD_VERIFICATION_URL’

‘RESET_PASSWORD_VERIFICATION_ONE_TIME_USE’

‘RESET_PASSWORD_VERIFICATION_EMAIL_TEMPLATES’

‘RESET_PASSWORD_SERIALIZER_PASSWORD_CONFIRM’

‘REGISTER_EMAIL_SERIALIZER_CLASS’

‘REGISTER_EMAIL_VERIFICATION_ENABLED’

‘REGISTER_EMAIL_VERIFICATION_EMAIL_SENDER’

‘REGISTER_EMAIL_VERIFICATION_PERIOD’

‘REGISTER_EMAIL_VERIFICATION_URL’

‘REGISTER_EMAIL_VERIFICATION_EMAIL_TEMPLATES’

‘VERIFICATION_FROM_EMAIL’

‘VERIFICATION_REPLY_TO_EMAIL’

‘VERIFICATION_EMAIL_HTML_TO_TEXT_CONVERTER’

‘VERIFICATION_URL_BUILDER’

‘VERIFICATION_TEMPLATE_CONTEXT_BUILDER’

‘VERIFICATION_TEMPLATE_RENDERER’

‘VERIFICATION_TEMPLATES_SELECTOR’

‘CHANGE_PASSWORD_SERIALIZER_PASSWORD_CONFIRM’

‘PROFILE_SERIALIZER_CLASS’

‘SUCCESS_RESPONSE_BUILDER’

‘USE_NON_FIELD_ERRORS_KEY_FROM_DRF_SETTINGS’

‘NOT_AUTHENTICATED_PERMISSION_CLASSES’