The server advertises only S256 in its metadata but still accepted code_challenge_method=plain, and a challenge sent with no method at
all (which RFC 7636 reads as plain). With plain the challenge is
the verifier itself, so anyone who saw the authorization request could
redeem the code.
The authorization endpoint now accepts a challenge only with code_challenge_method=S256; plain or a missing method is refused
with "Unsupported PKCE code_challenge_method: use S256.". Registered
clients that send no challenge at all are unchanged, and codes issued
with plain before the upgrade still verify.
Deploy order: inbuxa-admin #112 must be live first. Until it is, a
console served over plain HTTP falls back to plain and would no
longer sign in. The webmail already sends S256 only.
Tests: system::system_tests adds OIDC cases for plain and for a
missing method, both refused; the suite passes. Fork checks clean.
The server advertises only S256 in its metadata but still accepted
`code_challenge_method=plain`, and a challenge sent with no method at
all (which RFC 7636 reads as `plain`). With `plain` the challenge is
the verifier itself, so anyone who saw the authorization request could
redeem the code.
The authorization endpoint now accepts a challenge only with
`code_challenge_method=S256`; `plain` or a missing method is refused
with "Unsupported PKCE code_challenge_method: use S256.". Registered
clients that send no challenge at all are unchanged, and codes issued
with `plain` before the upgrade still verify.
**Deploy order:** inbuxa-admin #112 must be live first. Until it is, a
console served over plain HTTP falls back to `plain` and would no
longer sign in. The webmail already sends S256 only.
Tests: `system::system_tests` adds OIDC cases for `plain` and for a
missing method, both refused; the suite passes. Fork checks clean.
The authorization endpoint took the plain method, and assumed it when a
challenge came without a method (RFC 7636's default), for every client
but stateless ones, though the metadata lists only S256. With plain the
challenge is the verifier, so it protects nothing. Codes issued with
plain before an upgrade still verify.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The server advertises only S256 in its metadata but still accepted
code_challenge_method=plain, and a challenge sent with no method atall (which RFC 7636 reads as
plain). Withplainthe challenge isthe verifier itself, so anyone who saw the authorization request could
redeem the code.
The authorization endpoint now accepts a challenge only with
code_challenge_method=S256;plainor a missing method is refusedwith "Unsupported PKCE code_challenge_method: use S256.". Registered
clients that send no challenge at all are unchanged, and codes issued
with
plainbefore the upgrade still verify.Deploy order: inbuxa-admin #112 must be live first. Until it is, a
console served over plain HTTP falls back to
plainand would nolonger sign in. The webmail already sends S256 only.
Tests:
system::system_testsadds OIDC cases forplainand for amissing method, both refused; the suite passes. Fork checks clean.