Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

auth.md: clarify status codes vs redirect for OAuth error modes

Open Beginner friendly
#42 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
82/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Quiet
Domain
authentication, documentation

Research direction

Start with the Errors section in specs/api/auth.md, then compare its OAuth failure modes with the github-oauth plan and specs/screens/login.md. Update the spec so browser callback failures consistently document redirects with ?error=, while retaining bare status codes only for non-browser callers if that distinction is specified.

Written by the indexing model from the issue text.

Description

The Errors section of specs/api/auth.md lists `oauth_state_mismatch` and `oauth_session_invalid` as `401 unauthenticated` responses, while `github_unreachable` and `email_unverified` are documented as `502`/`403` with explicit redirect to `/login?error=`.

The github-oauth plan adopts the redirect strategy uniformly: every failure mode in the browser OAuth callback redirects to `/login?error=`. That matches specs/screens/login.md which expects `?error=` rendering, and is what makes sense for a callback the browser hits directly.

Should the spec be updated to:

  • list every OAuth error as 'redirect with `?error=`' (the actual user experience), and
  • reserve the bare-status-code shape for non-browser callers (e.g., if the API ever exposes the same flow to a CLI client)?

Filed in the github-oauth closeout — non-blocking for that plan, but worth a small spec edit.
Dominant language
TypeScript
Stars
1
Forks
1
Avg merge
1d 20h
Merged PRs (30d)
25

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CodeForPhilly/codeforphilly-ng

All issues in CodeForPhilly/codeforphilly-ng

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.