ABHA Login — Test Plan

Scope: what's actually wired in patient/src/ today. Login (5 paths) + 401-refresh interceptor + logout-with-revoke. Multi-ABHA scenarios (mobile-OTP users[] selection) where the FE handles them. DB tables to inspect after each scenario.

API source of truth: docs/abdm/api-reference/phr-login.md, phr-patient-profile-fetch.md, phr-profile-management.md.

Recent change (must re-verify on next pass): the backend patient-side login flow now upserts a Phr::AbhaProfile row per linked ABHA. Specifically:

• verify_mobile_otp_service upserts one row per users[] entry in the multi-ABHA case (after GenerateKulcareSessionService.call(...))
• generate_kulcare_session_service upserts one row when abha_address is present (every other login flow that calls this service — single-ABHA Mobile OTP, ABHA Number, ABHA Address × Aadhaar / Mobile / Password, etc.)
• The single-ABHA Mobile OTP path: verify_mobile_otp skips GenerateKulcareSessionService (no abha_address yet — user will pick one via verify_user); verify_user_service calls generate_kulcare_session(abha_address: selected) which goes through GenerateKulcareSessionService → upsert. Net effect: one row is upserted per successful login, regardless of which path.

NOT covered by this guide (out of scope / not wired in the FE yet): /phr/registrations/* (no FE consumer), /phr/patients/* (no FE consumer), /phr/profile/* (no FE consumer). The backend endpoints exist but the patient app doesn't call them — test those separately against Postman or backend integration tests.

1. What's actually in the patient appCopy Anchor Link

Run these greps first to confirm what's wired before testing:

# Service methods (12 login + refreshToken + revokeSession = 14)
grep -E "^  [a-zA-Z]+\(" patient/src/services/phr-auth.service.ts | head -20

# FE components that call phrAuthService
grep -rE "phrAuthService\." patient/src/features/auth/ patient/src/pages/ --include="*.tsx" --include="*.ts"

# Route paths declared in PHR_ENDPOINTS
grep -E "= '/(login|profile|patients)" patient/src/constants/api.ts

# Router wiring
grep -E "Route path=\{?APP_ROUTES" patient/src/app/App.tsx | head

# Logout invocation
grep -rE "logout\(\)" patient/src/components/ patient/src/app/ | head

# Backend upserter (this morning's fix)
grep -rn "ProfileUpserter" backend/domains/phr/services/login/

Expected output:

• 14 PHR_ENDPOINTS constants (5 login flows × 2 stages + refresh_token = 14, plus the PROFILE_SESSIONS_REVOKE constant added in G2)
• LoginForm.tsx + AbhaOtpVerification.tsx are the only FE consumers of phrAuthService
• 12 service methods for login + refreshToken + revokeSession
• Routes: /login, /abha-verify-otp, plus post-login /dashboard
• Logout invoked from AppSidebar.tsx
• Backend: ProfileUpserter exists in backend/domains/phr/services/login/profile_upserter.rb

2. Login flows (FE-side testing — what to click)Copy Anchor Link

For each scenario below: exercise the FE flow in the browser (open DevTools → Network tab → filter phr to capture the actual request/response), then inspect the DB tables in §7.

2.1 Mobile OTP (Section 6.3) — sendMobileOtp + verifyMobileOtp + verifyUserCopy Anchor Link

Files: LoginForm.tsx (method selection → mobile input form), AbhaOtpVerification.tsx (OTP + profile selection)

Scenarios:

DB checks after successful login (apply your DB client):

2.2 ABHA Address — Mobile OTP (Section 12.1)Copy Anchor Link

Files: LoginForm.tsx (method → OTP type picker → address form), AbhaOtpVerification.tsx

2.3 ABHA Address — Aadhaar OTP (Section 6.1)Copy Anchor Link

2.4 ABHA Number — Mobile OTP (Section 6.2)Copy Anchor Link

2.5 ABHA Number — Aadhaar OTP (Section 6.1)Copy Anchor Link

Same pattern as 2.4 with Aadhaar subtitle. phr.requests action=abha_number_aadhaar_verify_otp.

2.6 Password login (§12)Copy Anchor Link

3. 401-refresh interceptor (G1)Copy Anchor Link

Files: patient/src/api/phr-client.ts (interceptor), patient/src/services/phr-auth.service.ts (refreshToken method)

3.1 Happy path: refresh + retryCopy Anchor Link

Setup: log in successfully → DevTools → Application → Local Storage → kulcare-auth-token + kulcare-refresh-token are populated.

3.2 Refresh-fails edge casesCopy Anchor Link

3.3 Known gap (documented)Copy Anchor Link

The phr-client request interceptor sets REQUEST-ID + TIMESTAMP on every request, but does NOT inject X-token (the ABDM session token). The interceptor's refresh-on-401 path is the only way the FE authenticates for endpoints that don't set X-token explicitly (e.g. /phr/patients/*, /phr/profile/*). The plan's refresh flow works for these.

phrAuthService.verifyUser and refreshToken set the X-Token header per-call and don't go through the interceptor — they work directly.

4. Logout + session revocation (G2)Copy Anchor Link

Files: patient/src/stores/auth.store.ts (logout action), patient/src/services/phr-auth.service.ts (revokeSession), patient/src/components/layout/AppSidebar.tsx (logout UI trigger)

4.1 Happy path: identity logout + phr revokeCopy Anchor Link

4.2 Edge casesCopy Anchor Link

5. Multi-ABHA scenariosCopy Anchor Link

5.1 First-login users[] selection (verifyMobileOtp)Copy Anchor Link

Setup: mobile 9876543210 is linked to multiple ABHAs in sandbox.

5.2 JWT active-profile claim inspectionCopy Anchor Link

Test: decode the JWT after login (use jwt.io or any JWT decoder). Verify the active_abha_profile_id claim equals the selected profile's id. On any subsequent login (same ABHA, same profile), the claim should be unchanged.

6. Resend / guard / state (small UX tests)Copy Anchor Link

7. DB tables to inspect (no SQL — use your DB client)Copy Anchor Link

8. Reporting failuresCopy Anchor Link

For each failure:

Test ID:        [e.g. 2.1.2]
Steps taken:    [paste actions]
Expected:       [from the table]
Actual:         [observed]
FE console:     [errors]
Network tab:    [request/response bodies]
DB state:       [which tables you checked + values]
Reproduction:   [steps]
Root cause:     [your analysis]
Fix:            [proposed fix or N/A — backend issue]