Skip to content
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

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

pietrygamat
Copy link
Contributor

@pietrygamat pietrygamat commented Apr 14, 2024

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:

  • Clicking Get Access Token (or simplly running the request) results in bruno executing correct flow.
  • User may be prompted to provide password, depending on the grant type.
  • After the request completes, the oauth2 credentials are stored and displayed in collapsible section at the bottom of the screen.
  • Any subsequent requests witin the same collection will reuse them.
  • Clearing cache resets everything back.

Screenshot from 2024-05-05 22-01-00
Screenshot from 2024-05-05 22-01-33
Screenshot from 2024-05-05 22-02-11
Screenshot from 2024-05-05 22-03-28

Collection level

  • The same controls are added to collection level Auth configuration.
  • Clicking Get Access Token on collection level results in executing authorization request and updating credentials.
  • Inherit mode is now supported also when collection uses OAuth2.
    Screenshot from 2024-05-05 22-04-26
    Screenshot from 2024-05-05 22-04-45

Contribution Checklist:

  • The pull request only addresses one issue or adds one feature.
  • The pull request does not introduce any breaking changes
  • I have added screenshots or gifs to help explain the change if applicable.
  • I have read the contribution guidelines.
  • Create an issue and link to the pull request.

resolves #1999
resolves #2074
resolves #1704

@pietrygamat pietrygamat changed the title Feature/inherit oauth Improvements to OAuth2-related user interface Apr 14, 2024
@pietrygamat pietrygamat changed the title Improvements to OAuth2-related user interface feat: Improvements to OAuth2-related user interface Apr 14, 2024
@pietrygamat pietrygamat force-pushed the feature/inherit-oauth branch 4 times, most recently from 1ea0338 to 6f58145 Compare April 16, 2024 09:43
Copy link
Contributor

@lizziemac lizziemac left a 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

@pietrygamat pietrygamat force-pushed the feature/inherit-oauth branch 2 times, most recently from 82c01cf to b1b699a Compare May 5, 2024 17:22
@lizziemac
Copy link
Contributor

Looks great, I'm not sure but it looks like one of your other PRs (implicit grant) snuck in here

@pietrygamat
Copy link
Contributor Author

pietrygamat commented May 5, 2024

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.

Mateusz Pietryga and others added 3 commits June 2, 2024 18:07
… 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants