GitHub sign in
A second OAuth application for signing in, which is not the same one that pushes code.
GitHub appears twice in this installation and the two appearances are different applications that must not be confused:
| Application | Names | What it is for |
|---|---|---|
| Sign in (this page) | GITHUB_CLIENT_ID, GITHUB_CLIENT_SECRET | The GitHub button on the sign-in screen |
| Connect | GITHUB_CONNECT_CLIENT_ID, GITHUB_CONNECT_CLIENT_SECRET | Letting a user save their project into their own repository |
The first is read by the deployment, the second by the app. Both are created in the same place, and GitHub lets you have as many as you like.
The walkthrough
Create the application
GitHub, then Settings → Developer settings → OAuth Apps → New OAuth App. Developer settings is at the bottom of the personal settings sidebar, and it is also reachable at the organisation level, which matters if the product belongs to an organisation rather than to you.
Fill in the three fields
| Field | What to put |
|---|---|
| Application name | Your product's name, which is what people see on the authorisation screen |
| Homepage URL | Your app's address, https://loomis.your-domain.com |
| Authorization callback URL | https://loomis.your-domain.com/api/auth/callback/github |
For a laptop, the callback is http://localhost:3000/api/auth/callback/github.
GitHub takes one callback per application
Unlike Google, GitHub's OAuth app form holds a single callback address. That is why a laptop and a server want two applications, or one application whose callback is changed when you switch between them. The second is more convenient until it is forgotten, and then sign in works on the machine you are not using.
Generate the secret, and copy both values
Press Generate a new client secret. It is shown once. Copy it and the client ID, which is on the same screen.
Set them on the deployment
npx convex env set GITHUB_CLIENT_ID "Iv1.0123456789abcdef"
npx convex env set GITHUB_CLIENT_SECRET "your-secret"Add --prod on the production deployment.
Try it
/sign-in, press GitHub, and authorise. The authorisation asks for the identity claims only: an
address and a profile. Nothing is requested about repositories, which is exactly why the connect
application exists separately.
When it does not work
Telling your users what the two buttons are
Both buttons do the same thing to a person: they sign in without inventing a password. What differs is where the account exists and what happens if the provider is unreachable for an afternoon. A useful sentence for a support page, in your own words, is that either button creates a separate account here, and that an account made with an email address and a password can be recovered by email while the other two cannot.