fix(auth): enforce read-only sessions on all write routes #94

Merged
icub3d merged 1 commit from feature/77-readonly-enforcement into main 2026-07-08 03:35:54 +00:00
Owner

Summary

Fixes #77. The is_read_only session flag (unapproved/revoked bots) was enforced in exactly one handler (create_message). Every other write route — reactions, attachments, message edit/delete, profile updates, invite creation — ignored it, so a read-only session could still mutate state.

Fix

Enforce it centrally in the AuthUser extractor: reject any request whose session is read-only and whose HTTP method is unsafe (POST/PUT/PATCH/DELETE) with 403. Every authenticated handler funnels through AuthUser (directly or via MemberUser/UserPermissions), so this covers all current and future write routes with no per-handler duplication and no extra DB lookup. Removed the now-redundant check in create_message.

Safe methods (GET/HEAD/OPTIONS) are unaffected — read-only sessions keep read access.

Tests

  • New read_only_session_blocks_writes_but_allows_reads: a member's normal session posts (baseline 200), then a read-only session for the same member gets 403 on POST and 200 on GET.
  • Existing bot_approval_flow still passes (unapproved bot write → 403, approved bot re-auth → writable).

Full server suite green (116 tests); clippy -D warnings clean.

Closes #77

## Summary Fixes #77. The `is_read_only` session flag (unapproved/revoked bots) was enforced in exactly one handler (`create_message`). Every other write route — reactions, attachments, message edit/delete, profile updates, invite creation — ignored it, so a read-only session could still mutate state. ## Fix Enforce it **centrally** in the `AuthUser` extractor: reject any request whose session is read-only and whose HTTP method is unsafe (POST/PUT/PATCH/DELETE) with `403`. Every authenticated handler funnels through `AuthUser` (directly or via `MemberUser`/`UserPermissions`), so this covers all current and future write routes with no per-handler duplication and no extra DB lookup. Removed the now-redundant check in `create_message`. Safe methods (GET/HEAD/OPTIONS) are unaffected — read-only sessions keep read access. ## Tests - New `read_only_session_blocks_writes_but_allows_reads`: a member's normal session posts (baseline 200), then a read-only session for the same member gets 403 on POST and 200 on GET. - Existing `bot_approval_flow` still passes (unapproved bot write → 403, approved bot re-auth → writable). Full server suite green (116 tests); `clippy -D warnings` clean. Closes #77
fix(auth): enforce read-only sessions on all write routes
Some checks failed
CI / Client — test & lint (pull_request) Failing after 3s
CI / Server — test & lint (pull_request) Failing after 5s
Security Audit / PNPM Audit (JS SCA) (pull_request) Failing after 5s
Security Audit / Cargo Audit (Rust SCA) (pull_request) Failing after 6s
Security Audit / Semgrep (SAST) (pull_request) Failing after 8s
Security Audit / Trivy (SCA & IaC) (pull_request) Failing after 12s
Security Audit / Gitleaks (Secrets) (pull_request) Failing after 12s
37a44a5e91
Previously the is_read_only session flag (unapproved/revoked bots) was
checked in exactly one handler (create_message). Every other mutating
route — reactions, attachments, message edit/delete, profile updates,
invite creation, etc. — ignored it, so a read-only bot could still write.

Enforce it centrally in the AuthUser extractor: reject any request with a
read-only session and an unsafe HTTP method (POST/PUT/PATCH/DELETE). This
covers all current and future write routes since every authenticated
handler funnels through AuthUser. Removed the now-redundant per-handler
check in create_message.

Adds a regression test asserting a read-only session is 403 on POST but
200 on GET for the same member.

Closes #77

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
icub3d merged commit 291871e06a into main 2026-07-08 03:35:54 +00:00
icub3d deleted branch feature/77-readonly-enforcement 2026-07-08 03:35:55 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
icub3d/decentcom!94
No description provided.