POST /chat/create now checks project access before inserting
ryanmcdonough patches an authz hole in `POST /chat/create`: the endpoint previously accepted any `project_id` from the request body and inserted a chat row without verifying the caller had access to that project. Eight lines close it. Upstream willchen96/mike still has the gap.
The fix calls the existing checkProjectAccess(projectId, userId, userEmail, db) helper before the Supabase insert. The helper checks owner-or-shared-via-email - the same check every other project-scoped handler in the codebase performs. It was already present in projects.ts, tabular.ts, projectChat.ts, and other chat.ts handlers at lines 92, 287, 356, and 372. The chat creation path was simply missing it.
Without the check, any authenticated user could create a chat associated with a project they had no access to. The shared_with sharing model would have been bypassed entirely on that code path.
The handler returns 404 on access failure, matching the existing convention across the codebase. That's a deliberate choice: returning 404 avoids confirming whether a project ID exists to an unauthorized caller. The trade-off is that a caller debugging a misconfigured project ID gets the same response as one who genuinely lacks access - a known drawback the codebase has accepted throughout.
The change is small and the helper already exists. Re-applying this to another fork of willchen96/mike is a few minutes of work.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?