Add scheme/secureScheme ConsumerStrategy options #19
Conversation
This file contains 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
The sensible defaults are http and https for backwards compatibility
leskapaul
approved these changes
May 15, 2018
|
The passport project appears to be on life support w/o enough contributors to merge PRs :( |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The sensible defaults are http and https for backwards compatibility
There are additional protocol schemes which utilize vanilla HTTP/S, but enable additional functionality. The specific example I am submitting this to fix is websockets.
This is a long explanation for a tiny change:
Why is a change needed?
The scheme string is required to compute the OAuth 1.0a signature. Unfortunately the scheme is not transmitted in HTTP/1.1 requests. The only information known is whether TLS was used to secure the connection (
request.encrypted). Currently this project assumeshttpsif encryption was used, orhttpotherwise. In order to support additional standardized or custom schemes, some changes were needed.Why should Websocket support exist in an HTTP library!?
Websockets is HTTP as much as HTTPS is HTTP. In the case of HTTPS, the TLS steps happen up front, and is followed by a vanilla HTTP message structure. In the case of Websockets, it's pure HTTP (or HTTPS) up front, and then Websockets afterward. Both of these just build on HTTP, so it's all the same!