Skip to content

Calling Swagger UI via different context paths fails #2642

Closed
@hwanders

Description

@hwanders

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
    1. Call the UI via the reverse proxy (works fine)
    2. Call the UI via the service without the reverse proxy (fails)
  • First backend service - then reverse proxy
    1. Call the UI via the service without the reverse proxy (works fine)
    2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    incompleteincomplete description: Make sure you Provide a Minimal, Reproducible Example - with HelloController

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions