You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Client] Add an auth parameter to HttpTransport with BearerToken - #663
BearerToken is the only implementation for now, OAuth builds on AuthenticatorInterface in the next slices. No discovery or sign-in here, so the conformance baseline doesn't change yet.
[BC Break] A 401 or 403 now fails with an AuthorizationException that names the challenge, also without auth: - it was a RequestException before. connect() wraps it in a ConnectionException, without a retry.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Authentication defects can falsely report handshake success after a rejected notification, send empty or truncated retry payloads, block retries on unclosed response bodies, and misclassify SSE resumption authorization failures.
Adds client HTTP authentication as the first slice of #316, supporting existing bearer tokens and an extension point for future OAuth flows without adding discovery or sign-in.
Changes:
Adds HttpTransport::auth, BearerToken, and a PSR-18 decorator with bounded authentication retries.
Introduces AuthorizationException for refused requests and documents the compatibility change.
Adds tests for credential injection, challenge handling, and request-body replay.
The HTTP client gets decorated, so the transport keeps speaking plain PSR-18:
AuthenticatingHttpClient authenticates every request and retries the ones the
authenticator can act on. BearerToken sends a token you already have.
A 401 or 403 now fails with an AuthorizationException that names the challenge,
which connect() wraps in a ConnectionException without a retry.
…ayed
A 401 or 403 on a notification or a stream resumption now fails with an
AuthorizationException. A retry closes the rejected response first, and a
non-seekable body is not retried.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
The retry test’s string cast implicitly rewinds the stream, so it passes even without the decorator’s explicit rewind; using getContents() would verify that the body is restored before retrying.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Rewinding the request body to byte zero on retry can change the submitted payload when the stream initially starts at a nonzero position; retries must restore the original position.
No open issues 🎉
1 previously missed issue
In code that hasn't changed since last review
Retries rewind seekable request bodies to byte zero
With a seekable body initially positioned past byte zero, an HTTP client that reads using getContents() sends from that position on the first attempt, but this rewind makes the retry send the entire stream. This can change the submitted payload (for example, payload becomes prefix:payload); capture the initial stream position before the first send and seek back to it for retries.
The reason will be displayed to describe this comment to others. Learn more.
🟢 Approval recommended
No active review issues block the bearer-token authentication changes.
No open issues 🎉
Review effort: Balanced
This branch has not been deployed
No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
authIssues and PRs related to Authentication / OAuthClientIssues & PRs related to the Client component
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #316 - first slice of the client authorization in chr-hertel#53, which is too big to review in one go.
Pass
auth:toHttpTransportand every request gets authenticated, a refused one gets retried if the authenticator can do something about it:BearerTokenis the only implementation for now,OAuthbuilds onAuthenticatorInterfacein the next slices. No discovery or sign-in here, so the conformance baseline doesn't change yet.[BC Break] A
401or403now fails with anAuthorizationExceptionthat names the challenge, also withoutauth:- it was aRequestExceptionbefore.connect()wraps it in aConnectionException, without a retry.