servant-swagger-ui
servant-swagger-ui copied to clipboard
Using oauth2 securityScheme, redirectUrl is set to http://localhost:3200/oauth2-redirect.html
This seems to be part of the default config (see https://github.com/swagger-api/swagger-ui/blob/a86fcf312a0d9b04d99982bf88a3d95884eddb9a/swagger-config.yaml). For this to work, we would need to be able to override that URL to point to a page that's, you know, actually served by our server.
The behavior is similar to what's reported here.
There does not seem to be any way to override this config.
Any update on this?
Is it still an open issue ?
If someone knows what this is about, and have an idea how to fix it, then be my guest.
Simply put, I cannot reproduce this issue, as I don't fully understand what it's about.
when registering client applications with some identity providers (such as AWS Cognito; see https://aws.amazon.com/blogs/mobile/understanding-amazon-cognito-user-pool-oauth-2-0-grants/ ), the application defines the redirect URI that the identity provider redirects to - the redirect URI is tied to the clientID/secret. It must be passed to the auth server along with the client ID and client secret, and if the redirect URI does not match the one that is registered with the client application, the request fails. Since Swagger UI is not prompting for the redirect URI or passing it to the identity server, OAuth2 authentication fails.
Swagger UI configuration can set the redirect URI in index.html options to SwagerUIBundle via https://github.com/swagger-api/swagger-ui/blob/master/docs/usage/configuration.md .
This is still an issue on the latest version to date. I'm very confused about why this is still an issue, I see constant issue threads about resolving the issue and they have (mostly) all been closed.
The situation, I want to serve swagger UI from https://localhost:3000/api After cloning the repo I do the following:
`npm run build`
`docker build -t swag:0.0.26 .`
docker run -p 3000:8080 -e BASE_URL=/api swag:0.0.26
My swagger.json contains basically the default pets.json with the following change:
"securityDefinitions":{
"petstore_auth":{
"type":"oauth2",
"authorizationUrl":"<DNS>/auth/realms/customer-radar/protocol/openid-connect/auth",
"flow":"implicit"
}
Additionally in my index.html in dist/:
window.onload = function() {
// Begin Swagger UI call region
console.error("!!!! Starting Up 01\n\n\n\n")
print("!!!! Starting Up 02\n\n\n\n")
const ui = SwaggerUIBundle({
url: "<PathtoMyPublicAccessableSwagger.json>",
oauth2RedirectUrl: "/tester/oauth2-redirect.html",
dom_id: '#swagger-ui',
deepLinking: true,
presets: [
SwaggerUIBundle.presets.apis,
SwaggerUIStandalonePreset
],
plugins: [
SwaggerUIBundle.plugins.DownloadUrl
],
layout: "StandaloneLayout"
})
// End Swagger UI call region
window.ui = ui
ui.initOAuth({
clientId: "seldon",
realm: "customer-radar"
})
}
If I then hit https://localhost:3000/api I get redirected to swagger-ui.
If I hit authorize I see my client-id is populated with seldon.
If I hit authorize in the pop-up I get redirected to my Idp, I can enter my name and password and then get redirected back:
http://localhost:3039/oauth2-redirect.html#state=
What I expected to happen: In swagger-ui/docker/run.sh: BASE_URL (which is set as part of docker) should change nginx to server all traffic with the new base url.
What is happening: The redirect that is requested as part of the post to the the Idp does not go through Nginx thus the path will not be updated.
Temporary solution:
In swagger-ui/src/core/index.js this line:
oauth2RedirectUrl:
${window.location.protocol}//${window.location.host}/oauth2-redirect.html,
just update with the desired path
oauth2RedirectUrl:
${window.location.protocol}//${window.location.host}/api/oauth2-redirect.html,
Now it will redirect to my desired base URL of "API"
Additionally you will notice I did set oauth2RedirectUrl: "/tester/oauth2-redirect.html", in index.html. As far as I can tell it doesn't change anything.
I'm thinking it's not a file/overwrite issue as the oauthinit in the same file is working.
Just reiterating, there is about ~10 open issues that is dealing with this type of issue, there are also numerous closed issues which I'm assuming means someone tried to fix this? (Or do some issues get closed if they go stale, I'm not sure what the policy here is?)
Anyway I'm hoping the above is informative enough to help everyone else with this issue.