Invitations can only be accepted by the person signed in

The accept endpoint verifies the signed-in session matches the account the request claims to be, so a token alone cannot attach an arbitrary user to your company.

What it is

Server-side identity verification on the invite-accept route: the session user id must equal the user id in the request body, and a missing session is rejected outright.

Also called: invite security · someone else accepted my invite

See it
Invitations can only be accepted by the person signed in
🔒ridgelinepostframe.com/project/invite219
30×40 Garage
Framing · on schedule
Not visual — a sequence diagram of token + session, with the mismatch branch rejected. Sample data — no customer information appears here.
How it works
  1. 1The route requires a signed-in session and compares it to the claimed user id, returning 401 or 403 on mismatch.
  2. 2Every log line carries the route prefix plus the user and token so one person's full trace can be grepped.
Why we built it

The comment states the hole it closed: the route 'just trusted the clerkUserId in the body, which meant anyone holding a valid invite token + any Clerk user id could accept an invitation on behalf of that user (attaching them to an unwanted tenant)'. Because the route is public in middleware, the check had to move in-route.

The problem
  • A leaked invite token plus any known user id could attach a stranger to a tenant.
Sound familiar?
What you get
An invite can only ever attach the person actually holding the session.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →