fix (#1999) request url overwritten #2061
Open
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
pietrygamat
changed the title
pietrygamat
force-pushed
the
bugfix/1999-request-url-overwritten
branch
5 times, most recently
from
aabff55
to
85600d8
Compare
2 tasks
pietrygamat
force-pushed
the
bugfix/1999-request-url-overwritten
branch
3 times, most recently
from
0257ef9
to
4e97648
Compare
5 tasks
|
This may be superseded by a more complete #2077. |
pietrygamat
force-pushed
the
bugfix/1999-request-url-overwritten
branch
3 times, most recently
from
9db0485
to
f9a1e34
Compare
pietrygamat
force-pushed
the
bugfix/1999-request-url-overwritten
branch
from
f9a1e34
to
4a58438
Compare
This was referenced May 5, 2024
pietrygamat
force-pushed
the
bugfix/1999-request-url-overwritten
branch
3 times, most recently
from
363d357
to
bf9e6dd
Compare
2 tasks
… of api endpoint Setting oauth2 authorization no longer equals overwriting user-specified data in a request. The pre-requests made to obtain oauth2 access_token are now separated from actual API request. usebruno#1999
Results of oauth2 authorization flow (i.e. access_token but also refresh_token, id_token, scope or any other information returned from token request) are stored in a collection specific cache. It is persisted in the file system, and will be automatically reused when executing requests until the cache is purged (using Clear Cache button available in all related views).
…able by scripts The new variable 'credentials' is now available in 'req' object. It is added automatically during request preparation if oauth2 method is used and is value is either evaluated or retrieved from collection oauth2 cache.
…Token action The actual the authorization request is now part of request preparation, and its response is returned for post-request script processing.
According to RFC6749 Section 7.1, The client MUST NOT use an access token if it does not understand the token type. At this point bruno only understands 'bearer' token_type.
pietrygamat
force-pushed
the
bugfix/1999-request-url-overwritten
branch
from
bf9e6dd
to
b13260e
Compare
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.
Description
This PR changes how oauth2 authorization behaves. The current behavior is that user defined request is in most part overwritten by bruno and replaced with request for access token (following the specific OAuth2 flow). After this change, the token request will be executed separately, and obtained access token will be used to modify the user request's Authorization header.
Credentials caching
In order to avoid renewing access tokens for each request, bruno will cache the authorization response data. This information typically contains:
access_token,token_typeand some optional fields:refresh_token,expires_in,scope,sessionor whatever authrization server decides to include. The cached data is collection specific, and will be used if present. It may be cleared using clear cache button, together with other oauth2 session state.Automatically using token if token_type is bearer
After obtaining access token from authorization server or from cache, bruno will verify what is its
token_type. At this point bruno understandsbearertype, so if that's it - the user's request will be modified - theAuthorization Bearer $access_tokenheader will be added automatically, so the request should be successful. In cases where the token is of different type (e.g. mac encrypted) - bruno will not attempt anything, but user is free to use scripting capabilities to work with the token in any way they see fit. Support for other token_types may be added in the future, if there's a demand.Scripting
The token (and other data from authrization server response) are also available in scripting engine. The
reqobject now includes the.credentialsfield where they can be accessed in post-request script (and if #2249 is fixed, also in pre-request scripts). E.g. this is possible:More work is required for feature completeness:
Contribution Checklist:
resolves #1999