The /admin/ page holds the platform credentials the content pipeline uses, so it runs under the
tightest policy it can work with: no scripts, no images, no framing. Once its keys and its GitHub
app were configured on 26 October, it showed its “Sign in with GitHub” button. Clicking it did
nothing.
Why
The button is a small form that asks the Worker to start sign-in, and the Worker answers by
redirecting the browser to GitHub’s authorization screen. A page’s form-action policy decides
where a form may send the browser, and Chrome applies it to that redirect as well as to the form
itself. The policy already named the TikTok, Twitch, Instagram and Kick consent screens for exactly
this reason, because every Connect button works the same way. It did not name GitHub, so Chrome
stopped the redirect and stayed on the page. The only trace was an error in the browser console.
The fix
GitHub’s authorization address is now a single constant used both to build the sign-in redirect
and to build the policy, so they cannot disagree. The existing check confirmed each platform’s
consent screen was permitted but never looked at sign-in. A new one follows the redirect that
/admin/login actually sends and fails unless the policy permits its destination. Removing GitHub
from the policy on purpose made it fail.
Verification
- Reproduced against the live site in headless Chrome: clicking the button sent the request to
/admin/login, Chrome reported aform-actionviolation, and the page stayed on/admin/. - After the fix, against
npm run previewwith throwaway local keys: the same click went from/admin/to/admin/loginto GitHub’s authorization screen and on to GitHub’s sign-in page, with nothing in the console. tools/test-admin-connections.mjs22 of 22, including the new check.