Navigation Menu

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

Support for OpenAPI 3.0, specifically additional security schemes / JWT Bearer #3387

Closed
chorsnell opened this issue Jul 14, 2017 · 4 comments

Comments

@chorsnell
Copy link

chorsnell commented Jul 14, 2017

Not strictly an issue, more of a question, but when will swagger-ui have support for OpenAPI 3.0?

Specifically use of the additional security schemes for JWT + Bearer as per https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/versions/3.0.md#securitySchemeObject

Currently there are workarounds such as using api_key and appending Bearer before the token, but this is a bit of a pain / feels hacky.

Additionally is there a way to set one of the end points to take the response, eg the Bearer token, and then use that in subsequent requests without having to manually copy and paste the token into swagger-ui?

@fehguy
Copy link
Contributor

fehguy commented Jul 14, 2017

You should see an announcement almost any day now :)

@chorsnell
Copy link
Author

@fehguy oh wow, how's that for a quick response!! :)

Any chance there is going to be something usable in the next week or so? As I'm literally on the verge of starting a fairly large API build and it would be lovely to use it

@shockey
Copy link
Contributor

shockey commented Jul 14, 2017

@poppahorse, see #3083, #3338, and swagger-api/swagger-editor#1376 if you'd like to take a peek at how OAS3 is coming along. There's information in the branches on where to find the code if you'd like to play with it, but I caution you against using that code in a production deployment of UI or Editor.

Note that the new security and Try-It-Out features are not implemented (or scoped out) yet - but static rendering is pretty much there, and editing has most of the 2.0 creature comforts, except for validation.

OAS3 has a Link construct that we're planning to use in the UI to allow information from one operation execution to be mapped to parameter inputs in another operation... but I'm not sure that's exactly what you're asking for.

There's a proposal for a request/response interceptor in #2793 that would allow you to listen for a response from a magic endpoint. From there, as a workaround, you could grab the Bearer token out of the response and feed it into the UI using ui.authActions.authorize() as described in #3318 (comment). There's discussion for a more formal authorization interface in #2915.

Hopefully this gives you some jumping-off points for your use case. Please chime in on the linked tickets if you have anything to add to the conversation!

@chorsnell
Copy link
Author

chorsnell commented Jul 18, 2017

thanks @shockey I will have a look :) ta for all the references

@shockey shockey closed this as completed Aug 16, 2017
@lock lock bot locked and limited conversation to collaborators Jul 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants