Settings¶
You can provide DJOSER settings like this:
DJOSER = {
'PASSWORD_RESET_CONFIRM_URL': '#/password/reset/confirm/{uid}/{token}',
'USERNAME_RESET_CONFIRM_URL': '#/username/reset/confirm/{uid}/{token}',
'ACTIVATION_URL': '#/activate/{uid}/{token}',
'SEND_ACTIVATION_EMAIL': True,
'SERIALIZERS': {},
}
Note
All following setting names written in CAPS are keys on DJOSER dict.
USER_ID_FIELD¶
Name of a unique field in User model to be used as id for /users/<id>/ endpoints.
This is useful if you want to not change default primary key of the User model and hide from public.
Default: User._meta.pk.name where User is the model set with Django’s setting AUTH_USER_MODEL.
LOGIN_FIELD¶
Name of a field in User model to be used as login field. This is useful if you
want to change the login field from username to email without providing
custom User model.
Changed in version 2.3.0.
As the authentication is happening within the Django’s authentication backends, you need a
custom authentication backend that’s using LOGIN_FIELD instead of User.USERNAME_FIELD
for this setting to work as expected.
If you don’t want to roll out your own authentication backend, LoginFieldBackend has been prepared.
It works the same as ModelBackend, but it is using LOGIN_FIELD instead of User.USERNAME_FIELD.
To make your code backward compatible with previous Djoser versions, add this auth backend to your Django settings:
AUTHENTICATION_BACKENDS = [
"djoser.auth_backends.LoginFieldBackend",
]
Please notice that it is not recommended way of authentication and it may be removed in the future Djoser versions.
Default: User.USERNAME_FIELD where User is the model set with Django’s setting AUTH_USER_MODEL.
Warning
Djoser uses djangorestframework-simplejwt to provide a convenient integration for JWT. If you want to change LOGIN_FIELD for JWT you need to rely on their documentation and their settings as it’s another library. Changing Djoser setting doesn’t affect JWT resources.
PASSWORD_RESET_CONFIRM_URL¶
URL to your frontend password reset page. It should contain {uid} and
{token} placeholders, e.g. #/password-reset/{uid}/{token}.
You should pass uid and token to reset password confirmation endpoint.
Required: True
USERNAME_RESET_CONFIRM_URL¶
URL to your frontend username reset page. It should contain {uid} and
{token} placeholders, e.g. #/username-reset/{uid}/{token}.
You should pass uid and token to reset username confirmation endpoint.
Required: True
EMAIL_FRONTEND_PROTOCOL¶
If set, it will replace the PROTOCOL part of the url in the emails content.
EMAIL_FRONTEND_DOMAIN¶
If set, it will replace the DOMAIN part of the url in the emails content.
EMAIL_FRONTEND_SITE_NAME¶
If set, it will replace the SITE_NAME in the emails content.
SEND_ACTIVATION_EMAIL¶
If True user will be required to click activation link sent in email after:
creating an account
updating their email
Default: False
SEND_CONFIRMATION_EMAIL¶
If True, register or activation endpoint will send confirmation email to user.
Default: False
PASSWORD_CHANGED_EMAIL_CONFIRMATION¶
If True, change password endpoints will send confirmation email to user.
Default: False
USERNAME_CHANGED_EMAIL_CONFIRMATION¶
If True, change username endpoints will send confirmation email to user.
Default: False
ACTIVATION_URL¶
URL to your frontend activation page. It should contain {uid} and {token}
placeholders, e.g. #/activate/{uid}/{token}. You should pass uid and
token to activation endpoint.
Required: True
USER_CREATE_PASSWORD_RETYPE¶
If True, you need to pass re_password to
/users/ endpoint, to validate password equality.
Default: False
SET_USERNAME_RETYPE¶
If True, you need to pass re_new_username to
/users/set_username/ endpoint, to validate username equality.
Default: False
SET_PASSWORD_RETYPE¶
If True, you need to pass re_new_password to /users/set_password/
endpoint, to validate password equality.
Default: False
PASSWORD_RESET_CONFIRM_RETYPE¶
If True, you need to pass re_new_password to /users/reset_password_confirm/
endpoint in order to validate password equality.
Default: False
USERNAME_RESET_CONFIRM_RETYPE¶
If True, you need to pass re_new_username to
/users/reset_username_confirm/ endpoint in order to validate username equality.
Default: False
LOGOUT_ON_PASSWORD_CHANGE¶
If True, setting new password will logout the user.
Default: False
Note
Logout only works with token based authentication.
PASSWORD_RESET_SHOW_EMAIL_NOT_FOUND¶
If True, posting a non-existent email to /users/reset_password/ will return
a HTTP_400_BAD_REQUEST response with an EMAIL_NOT_FOUND error message
(‘User with given email does not exist.’).
If False (default), the /users/reset_password/ endpoint will always return
a HTTP_204_NO_CONTENT response.
Please note that setting this to True will expose information whether
an email is registered in the system.
Default: False
USERNAME_RESET_SHOW_EMAIL_NOT_FOUND¶
If True, posting a non-existent email to /users/reset_username/ will return
a HTTP_400_BAD_REQUEST response with an EMAIL_NOT_FOUND error message
(‘User with given email does not exist.’).
If False (default), the /users/reset_username/ endpoint will always return
a HTTP_204_NO_CONTENT response.
Please note that setting this to True will expose information whether
an email is registered in the system.
Default: False
TOKEN_MODEL¶
Points to which token model should be used for authentication. In case if
only stateless tokens (e.g. JWT) are used in project it should be set to None.
Example: 'knox.models.AuthToken'
Default: 'rest_framework.authtoken.models.Token'
SERIALIZERS¶
Dictionary which maps djoser serializer names to serializer classes (use dotted path). This setting provides a way to easily override given serializer(s) - it is used to update the defaults, so by providing, e.g. one key, all the others will stay default.
Note
Key 'user' is used for general users whereas 'current_user' lets you set
serializer for special /users/me endpoint. They both default to the same serializer though.
Examples
{
'user': 'myapp.serializers.SpecialUserSerializer',
}
Default:
{
'activation': 'djoser.serializers.ActivationSerializer',
'password_reset': 'djoser.serializers.SendEmailResetSerializer',
'password_reset_confirm': 'djoser.serializers.PasswordResetConfirmSerializer',
'password_reset_confirm_retype': 'djoser.serializers.PasswordResetConfirmRetypeSerializer',
'set_password': 'djoser.serializers.SetPasswordSerializer',
'set_password_retype': 'djoser.serializers.SetPasswordRetypeSerializer',
'set_username': 'djoser.serializers.SetUsernameSerializer',
'set_username_retype': 'djoser.serializers.SetUsernameRetypeSerializer',
'username_reset': 'djoser.serializers.SendEmailResetSerializer',
'username_reset_confirm': 'djoser.serializers.UsernameResetConfirmSerializer',
'username_reset_confirm_retype': 'djoser.serializers.UsernameResetConfirmRetypeSerializer',
'user_create': 'djoser.serializers.UserCreateSerializer',
'user_create_password_retype': 'djoser.serializers.UserCreatePasswordRetypeSerializer',
'user_delete': 'djoser.serializers.UserDeleteSerializer',
'user': 'djoser.serializers.UserSerializer',
'current_user': 'djoser.serializers.UserSerializer',
'token': 'djoser.serializers.TokenSerializer',
'token_create': 'djoser.serializers.TokenCreateSerializer',
'provider_auth': 'djoser.social.serializers.ProviderAuthSerializer',
}
EMAIL¶
Dictionary which maps djoser email names to paths to email classes.
Same as in case of SERIALIZERS it allows partial override.
Examples
{
'activation': 'myapp.email.AwesomeActivationEmail',
}
Default:
{
'activation': 'djoser.email.ActivationEmail',
'confirmation': 'djoser.email.ConfirmationEmail',
'password_reset': 'djoser.email.PasswordResetEmail',
'password_changed_confirmation': 'djoser.email.PasswordChangedConfirmationEmail',
'username_changed_confirmation': 'djoser.email.UsernameChangedConfirmationEmail',
'username_reset': 'djoser.email.UsernameResetEmail',
}
CONSTANTS¶
Dictionary which maps djoser constant names to paths to constant classes.
Same as in case of SERIALIZERS it allows partial override.
Examples
{
'messages': 'myapp.constants.CustomMessages',
}
Default:
{
'messages': 'djoser.constants.Messages',
}
PERMISSIONS¶
Changed in version 2.0.
Dictionary that maps permissions to certain views across Djoser.
Note
Admin in class names refers to users that have is_staff flag set to True,
not superusers.
Examples
{
'user': ['djoser.permissions.CurrentUserOrAdminOrReadOnly']
}
Defaults
{
'activation': ['rest_framework.permissions.AllowAny'],
'password_reset': ['rest_framework.permissions.AllowAny'],
'password_reset_confirm': ['rest_framework.permissions.AllowAny'],
'set_password': ['djoser.permissions.CurrentUserOrAdmin'],
'username_reset': ['rest_framework.permissions.AllowAny'],
'username_reset_confirm': ['rest_framework.permissions.AllowAny'],
'set_username': ['djoser.permissions.CurrentUserOrAdmin'],
'user_create': ['rest_framework.permissions.AllowAny'],
'user_delete': ['djoser.permissions.CurrentUserOrAdmin'],
'user': ['djoser.permissions.CurrentUserOrAdmin'],
'user_list': ['djoser.permissions.CurrentUserOrAdmin'],
'token_create': ['rest_framework.permissions.AllowAny'],
'token_destroy': ['rest_framework.permissions.IsAuthenticated'],
}
HIDE_USERS¶
New in version 2.0.
If set to True, listing /users/ enpoint by normal user will return only
that user’s profile in the list. Beside that, accessing /users/<id>/
endpoints by user without proper permission will result in HTTP 404 instead of HTTP 403.
Default: True
SOCIAL_AUTH_TOKEN_STRATEGY¶
String path to class responsible for token strategy used by social authentication.
Example:
'myapp.token.MyStrategy'Default:
'djoser.social.token.jwt.TokenStrategy'