Files
Salon/docs/risks.md
T
2026-03-13 23:45:36 +03:00

3.1 KiB

Risks And Gaps

This file tracks known gaps and risks to address in future iterations.

Security And Auth

  • Phone normalization is KSA-focused and minimal; broaden for multi-country use.
  • OTP protections are basic; add device fingerprinting and IP throttling if needed.
  • 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.
  • 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.

Next Auth Review Points

  • Enforce normalized E.164 phone format at model/DB boundary (constraints, indexing, uniqueness behavior with nullable fields).
  • Add DB-level non-null + format guardrails for accounts_user.phone_number to complement service-level normalization.
  • 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).

Booking Integrity

  • Availability checks and overlap prevention are now enforced for staff bookings.
  • Race condition — fixed: BookingCreateSerializer.create() now locks the staff row with select_for_update() inside transaction.atomic() and re-runs the overlap check before inserting. Concurrent requests for the same staff slot are serialized at the DB level. Requires PostgreSQL in production (SQLite ignores FOR UPDATE but still serializes writes).
  • No timezone handling or business hours enforcement.
  • No cancellation rules or refund logic.

Payments

  • Moyasar payment creation, webhook reconciliation, and idempotency are implemented.
  • Moyasar capture and refund are implemented in the gateway; API endpoints for admin-initiated capture/refund can be added when needed.

Data And UX

  • Ratings are not recalculated from reviews.
  • No image upload or storage strategy for photos.
  • Booking lifecycle notifications are implemented; Authentica can deliver SMS when NOTIFICATION_PROVIDER=authentica.
  • Localization foundations are in progress; full Arabic translation coverage and RTL QA are still pending.

Ops And Compliance

  • No audit logs for admin actions.
  • No multi-tenant isolation or data export tooling.
  • No GDPR/PDPL data retention policies defined.