Letting people sign in
Email and password come with the app. Google and GitHub appear once you save your own keys.
What it is for
A sign-in screen is how the app knows which rows belong to whom.
Without it every visitor looks like the same person, and "my orders" cannot mean anything.
Six roles exist: customer, member, staff, author, admin, owner. Say which one may do what.
What you need
For email and password, nothing. Passwords are 8 to 128 characters and are never stored as text.
For the Google or GitHub button you register the app on their side and save two keys per provider in Project secrets.
A confirmation mail to the address people signed up with can go out too. See the email page.
The order to do it in
Ask for sign-in first, then say what each role sees. Doing it the other way round means rewriting the screens.
For social sign-in, copy the redirect address shown next to the preset and paste it into Google or GitHub. Then save the two keys. The button appears on its own.
How to check it worked
Sign up in the preview, sign out, sign back in. Then open a page a signed-out visitor should not see.
If a key is missing the app answers plainly instead of pretending. Nothing is half-connected.
Checking role by role is the surest test. A staff account must not open the admin screen.
What it will not do
- Company sign-in (SSO) is written but no identity provider is connected yet.
- Keys are per project. They are yours, not ours, and they never reach the browser.
- A social button with no keys saved does not appear at all.
- Nobody can look up a forgotten password, us included. The stored form cannot be turned back into the original.