bmersereau tries to close a fail-open auth hole in Mike

A proposed fix would have stopped missing config from quietly switching off authentication on the server.

securityinfrastructure

In the upstream code, if the server couldn't find its Supabase credentials - Supabase is the hosted backend Mike uses for accounts and login - it shrugged and trusted whatever user ID the caller claimed. A misconfigured deployment was an unlocked deployment. @bmersereau's patch makes the server refuse to start that path: no credentials, no request served, full stop. It also adds the auth layer its first real unit tests, covering the misconfiguration cases that previously slipped through.

The pull request was closed without being merged, so the original fail-open behaviour is still sitting in upstream Mike. The author noted that a separate build issue means the fix couldn't be fully exercised in CI without real credentials wired up, but the auth logic itself is self-contained.

So what Anyone evaluating a Mike-derived product for client work should ask the vendor how their deployment handles missing auth config - the default answer upstream is still 'let everyone in'.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?