Add a dev sign-in provider so a local checkout needs no OAuth application - #14
Open
jankarres wants to merge 1 commit into
Open
Add a dev sign-in provider so a local checkout needs no OAuth application#14jankarres wants to merge 1 commit into
jankarres wants to merge 1 commit into
Conversation
A fresh checkout cannot be signed into. Every provider needs credentials from Google, GitHub or Apple, so `GET /auth/providers` returns three disabled entries and the app stops at its login gate. Running the stack end to end is therefore gated on registering an OAuth application, which is a lot of setup for someone who only wants to see their change work. Set DEV_AUTH_EMAIL and a fourth provider, `dev`, appears. Choosing it signs you in as that address: nothing external is contacted, the authorization URL is the server's own callback, and everything after the callback (single-use state, exchange codes, browser cookies, deep links) is the same code path the real providers take. The account is upserted by email like any other. Two independent gates keep it out of production. It is enabled only when NODE_ENV is `dev`, which `central:start` hardcodes to `prod`, and only when DEV_AUTH_EMAIL is set. While disabled it is filtered out of `GET /auth/providers` entirely, so a production response is byte-identical to what it was before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A fresh checkout cannot be signed into at all: every provider needs credentials from Google, GitHub or Apple, so
/auth/providersreturns three disabled entries and onboarding, pairing and the app WebSocket stay out of reach. This adds adevprovider, switched on withDEV_AUTH_EMAIL, that signs you in as that address without contacting anyone. Closes #13.Making it a provider rather than a side door is what keeps it to about 50 lines: the authorization URL is the server's own callback, so the state, the exchange code, the cookies and the deep link are all paths you already have, and the account comes out of
upsertUserFromProviderlike any other.Keeping it out of production
Two gates, neither reachable through
.envalone.NODE_ENVmust bedev, whichcentral:starthardcodes and the schema defaults toprodwithout, andDEV_AUTH_EMAILmust be set. While disabled the provider is filtered out of/auth/providers, so a production response is byte-identical to today's. I checked rather than assumed: a prod-mode instance withDEV_AUTH_EMAILstill in the same.envreturned exactly the three original entries, andPOST /auth/oauth/dev/startwas refused while the same call against the dev instance succeeded.The obvious objection deserves a plain answer.
NODE_ENV=devalready fabricates a host for any id, skips host verification, echoes any CORS origin and bypasses the trusted-web-origin check, so an instance in that mode was never safe to expose. This joins that surface rather than widening it, and a third explicit flag is easy if you would rather have one.Testing
pnpm type-checkandbiome check central/clean. Against a local central and relay,devappears in/auth/providerswith the address set and is absent without, the callback sets the cookies, and the app reaches onboarding; from there I paired a real CLI host over the relay and browsed its filesystem as the signed-in dev user.Before you merge
The app has no label or icon for a
devprovider, so against a dev server its login screen renders that button with no caption. Cosmetic and only visible locally, but if you would rather the client stayed untouched I can expose the flow as an endpoint only. Same for anything else here: tell me and I will take care of it.