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

Provider-type check in the 2.7.0 evidence path is case-sensitive while preset resolution is not

Closed
  • Is something wrong?
#242 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@heskew is already working on this.

Since Oct 1, 2026.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
authentication

Research direction

Start in src/lib/handlers.ts around the 2.7.0 evidence path and compare its provider checks with case-insensitive resolution in src/lib/providers/index.ts and buildProviderConfig. Add a unit test for a provider value of 'GitHub' that produces emailProvenance 'github-authenticated' and check other config.provider comparisons for the same issue. Done means authenticated email evidence and account adoption work regardless of provider casing.

Written by the indexing model from the issue text.

Description

What happens

Provider presets resolve case-insensitively (getProvider() in src/lib/providers/index.ts: a config with provider: 'GitHub' picks the GitHub preset), but the 2.7.0 evidence path in src/lib/handlers.ts (~L458) decides the GitHub provenance with config.provider === 'github', case-sensitively. For a config whose provider is stored with any other casing, the authenticated /user/emails fetch still runs and sets the adapter provenance symbol, but emailProvenance stays 'unauthenticated' and emailAuthenticated is false.

Why it matters

  • The built-in account-adoption gate then refuses to adopt an existing account for a genuine, verified GitHub login on such a config.
  • An onLogin hook that follows docs/lifecycle-hooks.md and gates on authEvidence.emailAuthenticated denies the login outright. Found this way: a consumer whose per-tenant provider configs store provider: 'GitHub' (preset resolution accepts it) would have started denying real GitHub logins the moment its hook adopted the documented check.

Verified by reading main @ the 2.7.0 release; not executed.

Expected

Every provider-type comparison in the evidence path uses the same normalization as preset resolution (lowercase once at config build time in buildProviderConfig, or compare with toLowerCase()), with a unit test for a 'GitHub'-cased config producing emailProvenance: 'github-authenticated'. Worth a sweep for other === 'github' / === 'google' comparisons against config.provider.

Dominant language
JavaScript
Stars
1
Forks
3
Avg merge
7h 4m
Merged PRs (30d)
24

Getting set up

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 HarperFast/oauth

All issues in HarperFast/oauth

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.