bleedingdeacons / fellowship / 33907968763
90%

DEFAULT BRANCH: main
Ran
Jobs 1
Files 57
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 17.885% (+5.8%) from 12.077%
33907968763

push

github

web-flow 
feat: Microsoft, Facebook and password sign-in (#3)

* test: prove the Apple sign-in path, which had no tests at all

Fellowship's Sign in with Apple support was already complete -- provider,
registry, settings field and the id_token exchange -- and entirely
unverified. JwtVerifier is the code that decides whether a stranger's
claim about their own email address is true, and nothing exercised it.

Twenty-five tests, and the negative ones forge. Each mints a real RS256
token against a real keypair, serves a real JWKS through the fake HTTP
transport, then breaks exactly one thing: alg none, HS256 signed with
the published public key, the wrong signing key, another audience,
another issuer, a replayed nonce, an expired token, one issued in the
future, one with no exp, one with no iat. The positive case exists so
the negatives are known to fail for the reason claimed.

Two behaviours worth pinning because they are easy to regress: an
unknown kid costs a second JWKS fetch and then a refusal, and a genuinely
rotated key is found on that second fetch -- without which every sign-in
fails for the cache's whole hour after a provider rotates.

The provider's own decisions are thin and therefore easy to get wrong:
the address is lower-cased (Unity matches on it), email_verified is
required and accepted as both a boolean and the string Apple has shipped
at different times, and a private relay address is deliberately allowed
through to be refused by the member gate instead.

Keypairs are generated per test; a fixture would mean a private key in a
public repository.

* feat: Microsoft and Facebook sign-in, and the PKCE they needed

Hand offers four providers; Fellowship had two. These are the other two,
ported from Reach so the two servers do not disagree about how the same
provider works.

Facebook is the reason this is one change rather than two. Its token
endpoint refuses an exchange whose authorise leg carried a code_challenge
without a matching code_verifier, s... (continued)

609 of 3405 relevant lines covered (17.89%)

1.32 hits per line

Coverage Regressions

Lines Coverage ∆ File
241
0.0
0.0% fellowship/fellowship/src/Rest/DeviceAuthController.php
88
0.0
0.0% fellowship/fellowship/src/Admin/SettingsPage.php
53
0.0
0.0% fellowship/fellowship/src/Core/FellowshipServiceProvider.php
23
28.13
28.13% fellowship/fellowship/src/Auth/Providers/GoogleProvider.php
12
0.0
0.0% fellowship/fellowship/src/Core/Schema.php
2
85.29
-5.33% fellowship/fellowship/src/Auth/Providers/AppleProvider.php
1
93.55
93.55% fellowship/fellowship/src/Auth/StateStore.php
Jobs
ID Job ID Ran Files Coverage
1 33907968763.1 57
17.89
GitHub Action Run
Source Files on build 33907968763