-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Improvements to OAuth2-related user interface #2077
feat: Improvements to OAuth2-related user interface #2077
Conversation
c962014
to
50a5d16
Compare
1ea0338
to
6f58145
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
really wonderful, I hope this gets merged soon! 🚀 I had just a couple UI thoughts in the meantime
packages/bruno-app/src/components/CollectionSettings/Auth/OAuth2/CredentialsPreview/index.js
Outdated
Show resolved
Hide resolved
packages/bruno-app/src/components/RequestPane/Auth/OAuth2/CredentialsPreview/index.js
Outdated
Show resolved
Hide resolved
82c01cf
to
b1b699a
Compare
Looks great, I'm not sure but it looks like one of your other PRs (implicit grant) snuck in here |
It's kind of on purpose - they build up on top of eachother - the implicit grant actually requires dropping the current approach of transforming user request into token request and automatically setting Bearer token instead. I hope to get some definitive feedback from @helloanoop @sanjai0py or other maintainers on wheter the feature is unwelcome, and if so, adjust the PRs accordingly, but having two (or actually three if counting #2164) conflicting PRs is something I want to avoid. |
3d6ce16
to
5744e7f
Compare
5744e7f
to
a5e2d09
Compare
5890931
to
733ed88
Compare
733ed88
to
a39f750
Compare
150a501
to
2163067
Compare
db3eed0
to
9e3defd
Compare
Dear @helloanoop , When this PR will get merged as , this change is going to be fixing many issue of OAuth and Inheritance of OAuth |
9e3defd
to
291a616
Compare
291a616
to
bb383b1
Compare
OAuth interface improvements is a priority for us in Sep 2024. I will share more updates on this soon. |
…ad of api endpoint (usebruno#1999) 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.
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).
…o be usable 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.
…vel Get Access 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.
…utput pane fix: typo - rename OAuth2PasswordCredentials component fix: typo - Use the same name for AuthMode - OAuth 2.0 in collection and request level
bb383b1
to
3bd8f09
Compare
Waiting on this and the other OAuth changes to introduce Bruno as a solution for my team, would love to see this soon 🙏🏻 |
Hoping that this redesign will be available soon. It's important to our team to adopt Bruno. |
Any update on this? |
For anyone looking for a workaround in the meantime, I'll post mine. Until they make it work the way it's supposed to do, this does it just fine.
Set all the requests to use "No Auth". Essentially what this does is that for each request in the collection, there will be a pre-request fired to get the bearer token via OAuth2 as configured in the collection settings, and save this to the "oauth2_token" Bruno variable. Then, for any request in the collection, there will be a pre request action to get the token in that "oauth2_token" variable and inject it into the "Authorization Bearer" header. |
8f75414
into
usebruno:feat/oauth2-improvements
These improvements are now available in the experimental build here - https://github.com/usebruno/bruno-experimental-builds/releases/tag/oauth2-revamp-v1.39.0-2025.2.5 Goal is to have this released before the end of this month (Feb 2025) |
Just tested. I was able to create an OAuth 2 Client Credentials Auth at the Collection Level, and then inherit the auth via requests under the collections and it worked. I can now clean up 10 other collections that all have a "Get Token" request that I have to click first to test things. Thank you! |
Description
Redesign of OAuth2 UI. Shows tokens and other information obtained from Authorization Server in separate (rudimentary) part of UI, decoupling them from information coming from actual user request. With this change it is now possible to inherit OAuth2 configuration from collection level.
This PR is a continuation of work started in #2061 where caching of access token was first implemented (currently pending review).
Request level view:
Collection level
Contribution Checklist:
resolves #1999
resolves #2074
resolves #1704
resolves #2494