Skip to content

No routine upstream re-validation: me_view's re-resolution hook is gated off for every onboarded user #383

Description

@bderenzi

Found in the Brian/Simon multi-tenant workspace pair-debug session, 2026-08-03.

The gate

apps/users/auth_views.py:117-131me_view calls _atry_resolve_provider only when not onboarding_complete. And _aonboarding_complete (:83-89) is True if the user has any non-archived, connection-backed membership.

So the one hook that could re-validate upstream access on a routine request is dead for exactly the population that needs it: anyone who has ever successfully onboarded. Results are additionally cached 30s (:42, :113-115). This is a lazy onboarding hook mislabelled as a refresh path.

What does re-validate (and why it is not enough)

To be precise — and correcting an initial overstatement of "nothing re-validates":

  • apps/users/views.py:84-120 tenant_list_view (GET /api/auth/tenants/) does re-resolve all three providers, behind a 1-hour TTL (views.py:31). It also archives vanished tenants.
  • But it fires only when the SPA hits that endpoint, which happens in CreateWorkspaceModal and WorkspaceDetailPage — and is memoized per page session by frontend/src/api/userTenantsCache.ts. It is never on the chat, query, or artifact path.
  • apps/users/signals.py:125-145 resolves on OAuth login, but only for the provider just used — so logging in via Google/GitHub/password re-validates nothing. This is why Brian logged back in via a different provider and kept access.

So the accurate framing is: there is no routine upstream re-validation on the paths users actually exercise.

Related

  • Refresh user's tenant list #173 asks for periodic/on-login refresh — this is the "on access" half and identifies why the existing hook doesn't fire.
  • The fail-open-on-401 issue is a prerequisite: making this hook fire more often does nothing until a 401 is treated as revocation, because both paths swallow the raise.

Suggested direction

Either drop the onboarding_complete condition (accepting the upstream call cost, with a sensible TTL like tenant_list_view's), or move re-resolution to a periodic task per #173 and keep me_view cheap. The latter is probably right; the point of this issue is that the current hook gives a false sense that login-time revalidation exists.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingeffort:Simpact:securitypair-debug-2026-08-03Surfaced in the Brian/Simon multi-tenant workspace pair-debug session, 2026-08-03pd-wave:2P2: correctness hardening; no wrong answers today

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions