docs: clarify idempotent retry expectations for approval flows

Document serialized approval execution expectations and recommend bounded idempotent client retries for admin mutation workflows.
2026-02-26 12:58:50 +00:00
parent 878e2b98e6
commit bbcada1317
2 changed files with 2 additions and 0 deletions
@@ -137,6 +137,7 @@ This wrapper now delegates to `BlackWall\Auth\AuthClient`.
 - Handle provider CSV exports with formula-injection safety in mind if opening them in spreadsheet applications.
 - Treat generated enrollment URLs as secrets and keep them out of URL query strings and request logs.
 - For reverse-proxy deployments, harden trusted proxy/IP forwarding configuration to prevent spoofed client IP headers.
+- Keep client-side admin mutation retries idempotent; approval workflows can be lock-serialized and should not be assumed to execute twice.
 - Never place client secrets, refresh tokens, or access tokens in URL query strings.
 - For OIDC providers, include a per-request `nonce` in authorisation requests.
 - For direct Cryptbin API usage, send `key_b64url` on unwrap calls; provider rejects key-mismatch unwrap attempts with `403 Forbidden`.
@@ -156,6 +156,7 @@ Provider user/project assignment views may exclude disabled projects even if his
 - Treat provider CSV exports as untrusted input in spreadsheet tools; prefer importing into systems that neutralise formula cells.
 - Treat enrollment URLs as sensitive bearer material: do not place them in redirect query parameters, logs, or analytics tags; keep them in one-time server-side flash/session state.
 - If your deployment runs behind reverse proxies, ensure trusted-proxy configuration is strict so spoofed forwarding headers cannot bypass IP-based abuse controls.
+- For approval-driven admin mutations, assume provider-side execution is serialized per approval item; client retries should still be idempotent and bounded.
 - Configure OAuth client redirect URIs as HTTPS in production; reserve HTTP for localhost loopback testing only.
 - Assume provider rate limits are enforced per source identity (for example IP) and shared across related auth endpoints.
 - Treat report/export-style provider endpoints as high-cost and expect stricter rate limits.