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

Swagger Options for Authorization Flow with PKCE #4424

Open
nwehrli opened this issue Mar 14, 2025 · 1 comment
Open

Swagger Options for Authorization Flow with PKCE #4424

nwehrli opened this issue Mar 14, 2025 · 1 comment

Comments

@nwehrli
Copy link

nwehrli commented Mar 14, 2025

We recently wanted to integrate Authorization Flow with PKCE into Swagger from tapir. For this it seems like one needs to call

window.ui.initOAuth({
clientId: "CLIENT_ID",
usePkceWithAuthorizationCodeGrant: true,
scopes: "SCOPES",
});

after SwaggerUIBundle({ ....}) in swagger-initializer.js.

Furthermore, it seems as if there is no support for any general options one would want to pass to SwaggerUIBundle({...}) such as a custom oauth2RedirectUrl option.

Is there any reason, why these kind of options are not realized in SwaggerUIOptions and SwaggerUI?

If not, we would be happy to create a pull request which adds these options as part of SwaggerUIOptions and then adds code to SwaggerUI to inject them into swagger-initializer.js.

@adamw
Copy link
Member

adamw commented Mar 21, 2025

There's two ways to approach the problem:

  1. extend SwaggerUIOptions to cover the options you mention above. The complication here is that it might be more than just passing a dictionary of values to SwaggerUIBundle, as in your case you also need an additional invocation. So this might get complex quite quickly?
  2. only support the basic case OOTB. For anything more complex, you can create an endpoint which serves swagger-initializer.js with your custom content, and add it before the swagger UI endpoints, so that it takes precedence

I understand the extra effort required for 2., but 1. seems like a rabbit hole with never-ending changes.

Maybe a good middle ground would be to include in the options an optional full body of the swagger-initializer that should be served (maybe parametrized with URL to the yaml?), wdyt?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants