Password
Password set, reset, and change operations
Sets password for guest users (users with user_type=guest, typically created during checkout without registration).
Access Control:
Anonymous users: Returns
redirect_urlto home pageRegistered users (already have password): Returns
redirect_urlto password change pageGuest users: Can set password and become registered users
User Type Transition: Upon successful password set, user's user_type is changed from guest to registered.
Password Validation: Password strength validated according to AUTH_PASSWORD_VALIDATORS setting (Dynamic Configuration).
Response Behavior:
Non-AJAX requests: HTTP 302 redirect to
locationURLAJAX requests (X-Requested-With: XMLHttpRequest): JSON with
locationfield
Session cookie for authentication
Session cookie in format sessionid=<value>.
May use site-specific cookie name (e.g., osessionid).
CSRF token for state-changing requests
Set to 'XMLHttpRequest' for AJAX requests to receive JSON response
New password
Confirm new password (must match password1).
Validated against AUTH_PASSWORD_VALIDATORS setting.
Password set successfully (AJAX request). Returns location URL for redirect.
Password set successfully (non-AJAX request), redirects to location
Validation errors (AJAX request):
- Password mismatch (password1 != password2)
- Weak password (fails AUTH_PASSWORD_VALIDATORS)
Sets password for authenticated guest users with phone number verification via SMS OTP. This is a two-step process that transitions guest users to registered users.
Step 1 - Request OTP: Send phone, password1, password2 without code. System validates fields, sends SMS verification code, and stores confirmation data in session. Returns 202 status.
Step 2 - Verify and Set Password: Send all fields including code. System verifies the code against session confirmation data. If valid:
Password is set and validated against
AUTH_PASSWORD_VALIDATORSUser type changes from
guesttoregisteredPhone number is saved to user profile
verified_phoneattribute is set totrueOld password is saved to user profile history Returns 200 with success message.
Resend OTP: Use resend: true to request a new code. Subject to SMS resend interval restrictions (configured via SMS_OTP_RESENT_TIME_GAP system setting). Returns 202 status.
Phone Validation: Phone must be unique among active users (uses UNIQUE_VALIDATOR_PHONE_MESSAGE dynamic setting for error message).
Password Validation: Password strength validated according to AUTH_PASSWORD_VALIDATORS setting (Dynamic Configuration).
Throttling scope: register.
Session cookie for authentication
Session cookie in format sessionid=<value>.
May use site-specific cookie name (e.g., osessionid).
CSRF token for state-changing requests
New password
Confirm new password (must match password1)
Phone number for SMS verification
SMS verification code. Omit on first request to receive OTP.
Set to true to request a new verification code
falsePassword set successfully (Step 2 completed)
SMS verification code sent (Step 1 or resend). Confirmation data stored in session.
Validation errors:
- Password mismatch (password1 != password2)
- Weak password (fails AUTH_PASSWORD_VALIDATORS)
- Phone already exists for another active user
- Phone format invalid
- Incorrect OTP code during verification
Authentication required (must be logged in)
Too many requests:
- Throttling limit exceeded (register scope)
- SMS resend interval not elapsed
Initiates password reset flow by sending a reset link via email.
User Filtering: Only sends email to users who:
Are registered users (not guest users)
Have verified email addresses
Are active users
Email Content: Email is rendered using template from RESET_EMAIL_HTML_TEMPLATE setting (Dynamic Configuration). The email contains:
Password reset link with unique token
Frontend ID in extra context (from
X-Frontend-IDheader if valid)
Security: Always returns success (200) to prevent email enumeration, regardless of whether the email exists in the system.
User Translation: Email is sent in user's preferred language (user.language_code).
Throttling scope: password-reset.
Frontend identifier for multi-frontend setups.
Must be in VALID_FRONTEND_IDS setting (Dynamic Configuration).
Passed to email template context as frontend_id.
Email address for password reset link
Reset email sent if address exists. Response is identical for existing and non-existing emails to prevent enumeration.
Too many reset requests
Initiates password reset flow by sending a reset SMS with a password reset link to the provided phone number.
User Lookup: Searches for active users by phone number. Only sends SMS if:
Phone number exists in the system
User is active
SMS Content: SMS contains:
Site name
Password reset URL with token (format:
/password-reset/{uid}/{token}/)User information
Token Generation: A secure, time-limited token is generated for password reset confirmation.
Security: Always returns success message (200) to prevent phone number enumeration, regardless of whether the phone exists in the system.
Throttling scope: password-reset.
Phone number for password reset SMS
Success response (always returned regardless of phone existence). SMS is sent only if phone belongs to an active user.
Validation errors:
- Phone format is invalid
Throttling limit exceeded (password-reset scope)
Changes password for the currently authenticated user. Requires verification of the old password and two matching new password entries.
Password Validation: New password is validated against AUTH_PASSWORD_VALIDATORS setting (Dynamic Configuration).
Side Effects:
Old password is saved to user profile history
User type is updated to
registeredif not alreadyNotification email is sent asynchronously
Email Notification: A confirmation email is sent to the user with subject "Password Changed". CC/BCC recipients can be configured via EMAIL_BCC_AND_CC setting.
Audit Logging: Password change events are logged for security audit purposes. Password values are not stored in audit logs.
Error Handling: Invalid old password returns "Invalid password." error message.
Session cookie for authentication
Session cookie in format sessionid=<value>.
May use site-specific cookie name (e.g., osessionid).
CSRF token for state-changing requests
Current password
New password
Confirm new password (must match new_password1)
Password changed successfully
Validation errors:
- Invalid old password ("Invalid password.")
- Password mismatch (new_password1 != new_password2)
- Weak password (fails AUTH_PASSWORD_VALIDATORS)
Authentication required
Last updated
Was this helpful?