Global verification
List of settings
These settings can be used to configure how verification should work
(for things like registration, password reset, email change).
You should add them as keys (with values)
to your settings.REST_REGISTRATION dict.
‘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 theparam_signerunder'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 ofrest_registration.notifications.enums.NotificationTypeenum.notification_method- value ofrest_registration.notifications.enums.NotificationMethodenum. Currently there is only one choice which isNotificationMethod.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:
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 ofrest_registration.notifications.enums.NotificationTypeenum.notification_method- value ofrest_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).