dmr-from-dj-rest-auth

Move account flows (login, logout, registration, password reset, MFA, social) to django-allauth headless endpoints, then rebuild project-specific endpoints like user details as dmr controllers with typed DTOs. Migrate one flow at a time, starting with login, and update clients for every path or payload change.

dj-rest-auth endpoints map to allauth headless routes under /_allauth/{client}/v1/, for example login becomes POST /_allauth/{client}/v1/auth/login and logout becomes DELETE the session endpoint. User details has no allauth equivalent and must be rebuilt as your own dmr controller.

No, allauth headless serves its own paths and envelope format, so strict path parity is not achievable. Treat it as a coordinated frontend and backend migration; a compatibility shim re-serving old paths is possible but is a long-lived maintenance burden.

Use dmr's CookieJWTSyncAuth and re-declare cookie flags (httponly, secure, samesite, path) as NewCookie arguments and CookieSpec declarations, since REST_AUTH settings become code. dmr enforces CSRF automatically for cookie-based auth, replacing JWT_AUTH_COOKIE_USE_CSRF.

Custom validation and side effects in overridden serializers do not move automatically. Re-attach them to allauth adapters or signals (for account logic) or to your own dmr controllers (for domain logic), and add tests for each one since side effects like provisioning are easily lost.

dmr provides its own VerifyToken and RefreshToken controllers to replace simplejwt's token endpoints. Refresh-token rotation and blacklisting are not automatic; use the dmr jwt blocklist app if the project relied on simplejwt's blacklisting.