From eb88f23d28f1801a8a2c14ad9bc86f609b41bb66 Mon Sep 17 00:00:00 2001 From: mohd Date: Sat, 14 Mar 2026 00:48:05 +0300 Subject: [PATCH] chore: document auth fixes --- docs/risks.md | 4 ++-- docs/runbooks/payments_sanity_check.md | 10 +++++----- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/risks.md b/docs/risks.md index 8661fbb..9a02cdc 100644 --- a/docs/risks.md +++ b/docs/risks.md @@ -8,7 +8,7 @@ This file tracks known gaps and risks to address in future iterations. - Authentica OTP provider is implemented (SMS + WhatsApp via Authentica OTP). - Social login is a placeholder. - `USERNAME_FIELD` is now `"phone_number"`; `REQUIRED_FIELDS = []`; `create_superuser` accepts `phone_number`. Admin and `createsuperuser` work correctly for phone-only users. -- API currently exposes mixed auth paths (`/accounts/register/`, `/accounts/token/`, and phone OTP login), creating unclear source-of-truth for identity/auth policy. +- Password token obtain endpoint (`/api/auth/token/`) is deprecated (`410 Gone`); phone OTP flow is the login source of truth. - OTP purpose isolation is enforced at verification endpoint boundaries (`/otp/verify` accepts only `verify`, `/phone/verify` accepts only `auth`). - Django admin user configuration remains email-centric (ordering/add form defaults), increasing operational friction for phone-only accounts. - Multiple serializers/model `__str__` paths in non-auth apps still fallback to `user.email`; phone-only users may get poor display/audit clarity. @@ -18,7 +18,7 @@ This file tracks known gaps and risks to address in future iterations. - Decide user lifecycle for phone auth (create user before OTP verify vs provisional/pre-user state). - Expand abuse prevention beyond per-phone cooldown (IP throttling, device fingerprint, risk signals). - Define OAuth account-linking policy (phone/email conflicts, merge rules, trust source). -- Add explicit tests for phone-first invariants (null-phone rejection if required, token endpoint behavior, OTP purpose isolation, verified-phone guards). +- Add explicit tests for remaining phone-first invariants (verified-phone guards and any legacy-path regressions). ## Booking Integrity - Availability checks and overlap prevention are now enforced for staff bookings. diff --git a/docs/runbooks/payments_sanity_check.md b/docs/runbooks/payments_sanity_check.md index cb3c37b..a166ea6 100644 --- a/docs/runbooks/payments_sanity_check.md +++ b/docs/runbooks/payments_sanity_check.md @@ -58,18 +58,18 @@ Expected: server starts at `http://127.0.0.1:8000/`. ### 4) Obtain a JWT access token +Password token login at `/api/auth/token/` is deprecated for phone-first auth. For this runbook, mint a local JWT in Django shell. + The demo customer is: - `customer@example.com` - `Customer123!` -Fetch the access token: +Generate an access token: - curl -s -X POST http://127.0.0.1:8000/api/auth/token/ \ - -H "Content-Type: application/json" \ - -d '{"email":"customer@example.com","password":"Customer123!"}' + python3 manage.py shell -c "from django.contrib.auth import get_user_model; from rest_framework_simplejwt.tokens import RefreshToken; u=get_user_model().objects.get(email='customer@example.com'); print(str(RefreshToken.for_user(u).access_token))" -Expected: JSON containing `access` and `refresh` tokens. +Expected: a JWT string printed to stdout. Use it as ``. ### 5) Create a payment