hamid/baya-monorepo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

include product files

Browse Source
This commit is contained in:
hamid
2026-07-05 14:57:05 +03:30
parent b8934f531d
commit e2b22df2d6
1 changed files with 1 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
product/business/01-actors-and-onboarding.html
+1
View File
@@ -30,6 +30,7 @@
</li> </li>
<li>Each successful login creates a refresh-token session that can be revoked (logout, stolen-token detection).</li> <li>Each successful login creates a refresh-token session that can be revoked (logout, stolen-token detection).</li>
<li><strong>As-built decisions (backend-phase-2):</strong> each refresh <strong>rotates</strong> the session (old revoked, new pair issued); a refresh token presented against an already-revoked session is treated as <strong>stolen-token reuse → all of the user's sessions are revoked and the call returns 401</strong>. Logout rotates the security stamp, so every outstanding access token dies (other devices recover by refreshing). OTP request/verify never reveal whether a phone already has an account; one OTP per phone per resend window (<code>auth_otp_resend_seconds</code>), and after <code>auth_otp_max_attempts</code> wrong codes verification refuses until a fresh OTP. <code>customer</code>/<code>nurse</code> are the only self-selectable roles (a user may hold both; grants audited via <code>granted_by</code>/<code>granted_at</code>); any admin sub-role self-assign attempt returns <strong>403</strong> — admin provisioning is internal-only.</li> <li><strong>As-built decisions (backend-phase-2):</strong> each refresh <strong>rotates</strong> the session (old revoked, new pair issued); a refresh token presented against an already-revoked session is treated as <strong>stolen-token reuse → all of the user's sessions are revoked and the call returns 401</strong>. Logout rotates the security stamp, so every outstanding access token dies (other devices recover by refreshing). OTP request/verify never reveal whether a phone already has an account; one OTP per phone per resend window (<code>auth_otp_resend_seconds</code>), and after <code>auth_otp_max_attempts</code> wrong codes verification refuses until a fresh OTP. <code>customer</code>/<code>nurse</code> are the only self-selectable roles (a user may hold both; grants audited via <code>granted_by</code>/<code>granted_at</code>); any admin sub-role self-assign attempt returns <strong>403</strong> — admin provisioning is internal-only.</li>
<li><strong>As-built decisions (frontend-phase-2 — onboarding UI):</strong> the "who is care for?" onboarding step captures the patient's <strong>relation to the payer</strong> as a stable enum — <code>parent</code> | <code>spouse</code> | <code>child</code> | <code>self</code> (the <code>self</code> case still creates a distinct patient row; the customer is never collapsed into the patient). It also collects optional <strong>condition</strong> chips (<code>elderly</code>/<code>post_surgery</code>/<code>diabetes</code>/<code>mobility</code>/<code>dementia</code>). Neither <code>relation</code> nor <code>conditions</code> exists on the <code>patients</code> table yet — they are carried client-side and requested for the backend as <strong>REQ-005</strong> (frontend <code>requests/for-backend.md</code>); confirm/adjust the enum values when persisting.</li>
</ul> </ul>
<h2 id="b-iran-specific-considerations">(b) Iran-specific considerations <a class="anchor" href="#b-iran-specific-considerations" aria-hidden="true">#</a></h2> <h2 id="b-iran-specific-considerations">(b) Iran-specific considerations <a class="anchor" href="#b-iran-specific-considerations" aria-hidden="true">#</a></h2>
<ul> <ul>