Description
Requesting the Swagger UI from two different public URLs having different context paths causes the second UI initialization to fail. The second UI call will have a wrong path written in swagger-initializer.js
: configUrl
is based on the path from the first request.
To Reproduce
Setup a reverse proxy (for example at localhost:80) in front of a backend service BS (for example at localhost:8080) which adds a prefix to all the backend service's URLs. So the backend service endpoints are available at http://localhost:80/service/**
(reverse proxy with path prefix /service
) and http://localhost:8080/**
(backend service).
The backend service should be configured to provide a Swagger UI.
The following scenarios, each executed on a freshly restarted backend service, reproduce the problem:
- First reverse proxy - then backend service
- Call the UI via the reverse proxy (works fine)
- Call the UI via the service without the reverse proxy (fails)
- First backend service - then reverse proxy
- Call the UI via the service without the reverse proxy (works fine)
- Call the UI via the reverse proxy (fails)
I'm using springdoc-openapi-starter-webmvc-ui
version 2.6.0
.
Reason
SwaggerIndexPageTransformer
initializes the singleton SwaggerUiConfigParameters
by calling swaggerWelcomeCommon.buildFromCurrentContextPath(request)
if the configuration's configUrl
is null
. The configUrl
(and perhaps some other properties) is derived from the current request's context path.
Subsequent requests, even if they have a different context path, will use the initialized configuration without re-evaluating it.
The browser will then try to load the configuration from an URL which is not available.
Expected behavior
The configUrl
should be re-evaluated (if necessary) to generate a correct swagger-initializer.js
.
Ideas
Perhaps the SwaggerUiConfigParameters
shouldn't be modified at all by the transformer.
This is to avoid concurrency problems caused by a hypothetical re-evaluation overwriting the configuration.
I'm not sure whether SwaggerUiConfigParameters.configUrl
is a relevant public API for anybody. Changing or removing it is probably a breaking change.