fix(auth): move SMB auto-join from current_active_user to on_after_register

[awais786]

Summary

auto_join_smb_search_space was being called from current_active_user, FastAPI's per-request auth dependency. Combined with the hard-delete DELETE /searchspaces/{id}/members/{membership_id} endpoint (no tombstone column on SearchSpaceMembership), this made admin removal a no-op: the very next API request from a removed user re-INSERTed their membership row.

This PR moves the call to `on_after_register` so it fires exactly once per user, at creation time. Removed users stay removed.

Reproduction (against current main)

1. Owner Alice has an Editor Bob on the SMB workspace.
2. Alice: `DELETE /api/v1/searchspaces//members/` → 200.
3. `SELECT * FROM search_space_memberships WHERE user_id = ` → 0 rows.
4. Bob's frontend polls `GET /api/v1/searchspaces//documents` (with valid Bearer JWT).
5. `SELECT * FROM search_space_memberships WHERE user_id = ` → 1 row, role_id = Editor.
6. Bob has full Editor permissions back: `documents:create/read/update`, `chats:create/read/update`, `members:invite`, `connectors:create/update`.

Fix

`users.py`:

• Remove the two `auto_join_smb_search_space` calls from `current_active_user` (one in the proxy_user branch, one in the jwt_user branch).
• Add a single call inside `on_after_register`, after the personal default-SearchSpace setup commits.
• Update the docstrings on both functions to reflect the new placement and the reason.

Both registration paths land in `on_after_register`:

• Standard FastAPI Users register flow
• `ProxyAuthMiddleware._resolve_user` (already invokes `on_after_register` after creating a user via header-trust — see `proxy_auth.py:179-209`)

So new users from either flow are still auto-joined exactly once. Existing users at fix time who don't have an SMB membership row aren't backfilled — operators can do a one-time SQL INSERT against `search_space_memberships` for those.

Why not a tombstone column

A tombstone column on `SearchSpaceMembership` (`removed_at` or `is_blocked`) was the alternative — preserves the original "auto-join existing users when SMB workspace appears" UX while making removals durable. Larger change (schema migration + DELETE refactor + auto-join skip-tombstoned-users logic). Saved for a follow-up if the one-shot trade-off proves limiting.

Test plan

• Sign up a new user (proxy-auth path) → confirm SMB membership exists after registration.
• Sign up a new user (JWT/email-password path) → same.
• As Owner, DELETE an Editor's membership → confirm 0 rows in `search_space_memberships` for that user/space.
• As the removed Editor, hit any authenticated endpoint repeatedly → confirm membership row stays at 0 (does NOT re-INSERT).
• Sign out + back in as the removed Editor → confirm still no membership re-INSERT.
• Existing users who already have SMB memberships unaffected.

Refs

External writeup: awais786/sso-rules `surfsense-security.md` §Finding 1 (PR pending)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Moves the auto_join_smb_search_space call out of the per-request current_active_user dependency and into on_after_register, so it executes exactly once at user creation. Previously, every authenticated request from a removed user re-INSERTed their SMB membership row, because the DELETE .../members/{membership_id} endpoint hard-deletes without a tombstone — making admin removals effectively a no-op.

Changes:

• Add a single auto_join_smb_search_space(user.id) call at the end of UserManager.on_after_register, wrapped in try/except with logger.exception.
• Remove the two per-request auto_join_smb_search_space invocations (proxy_user and jwt_user branches) from current_active_user.
• Update docstrings to document the new placement and rationale.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.