OpenAPI 3.1.0: incorrect resolution using `https://smartbear.com` as `baseURI`

[char0n]

Thanks for the excellent work on implementing Open Api 3.1 support.
I tried to switch my schemas to 3.1 - and I see a problem with resolving $ref: paths in $ref are being resolved using smartbear.com as the host.
It's rather weird because I don't see smartbear.com in the swagger-ui code - I can't figure out where it then gets such a value as a host?
I tried to override this behavior by all means (including setting servers at the root of swagger.yaml, as well as by packing all $ref into components/schemas) - it didn't help.
Please fix determination of host when resolving $ref.

Originally reported in #5891 (comment) by @PatchRanger

[char0n]

@PatchRanger can you please describe steps of reproduction?

I've tried to reproduce using either spec URI or spec object, but with no luck. Do you use swagger-ui docker image or do you use SwaggerUI npm package with your configuration?

The smartbear.com host comes from swagger-client (specifically here) and it's a fail-safe mechanism if baseURI is not provided or cannot be computed.

---

It would help if you would fill the following bug template:

Q&A (please complete the following information)

• OS: [e.g. macOS]
• Browser: [e.g. chrome, safari]
• Version: [e.g. 22]
• Method of installation: [e.g. npm, dist assets]
• Swagger-UI version: [e.g. 3.10.0]
• Swagger/OpenAPI version: [e.g. Swagger 2.0, OpenAPI 3.0]

Content & configuration

Example Swagger/OpenAPI definition:

# your YAML here

Swagger-UI configuration options:

SwaggerUI({
  // your config options here
})

?yourQueryStringConfig

Describe the bug you're encountering

To reproduce...

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

Screenshots

Additional context or thoughts

[PatchRanger]

@char0n Thanks for detailed response, I am going to provide needed information.

Do you use swagger-ui docker image or do you use SwaggerUI npm package with your configuration?

The first: I am using swagger-ui docker image, specifically swaggerapi/swagger-ui:v5.0.0-alpha.4.

The smartbear.com host comes from swagger-client (specifically here) and it's a fail-safe mechanism if baseURI is not provided or cannot be computed.

Thanks for the clarification, now I understand it better - but in my case it looks weird nevertheless: I am sure I am passing BASE_URL env-variable.

OS: Ubuntu 22.04.1
Browser: Chromium-based
Version 108.0.0.0
Method of installation: via docker image swaggerapi/swagger-ui
Swagger-UI version: v5.0.0-alpha.4
Swagger/OpenAPI version: 3.1.0

schemas/internal/v1/swagger.yaml:

openapi: "3.1.0"

info:
  title: Internal API v1
  contact:
    email: support@example.com
  description: Internal REST-Full API
  version: "2.0"

paths:
  /api/internal/v1/ready:
    get:
      responses:
        200:
          content:
            application/json:
              schema:
                $ref: "ready/responses/ready-response.json"

schemas/internal/v1/ready/responses/ready-response.json:

{
  "title": "ReadyResponse",
  "description": "Ready status response",
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "data": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "ready": {
          "description": "Readiness",
          "type": "string"
        },
      }
    }
}

Here is how it is started:
docker/swagger/Dockerfile.swagger-ui:

ARG SWAGGER_IMAGE
FROM ${SWAGGER_IMAGE}

RUN ln -s /code/schemas/swagger /usr/share/nginx/html/swagger

This file passes BASE_URL env-variable - and that's why I am sure that it should be set. Looks like it is totally according to the docs: https://github.com/swagger-api/swagger-ui/blob/v5.0.0-alpha.4/docs/usage/installation.md#docker - or I am missing something? In my view it looks strange that configuration doc missing description of BASE_URL: https://github.com/swagger-api/swagger-ui/blob/v5.0.0-alpha.4/docs/usage/configuration.md - it makes me to doubt whether it could accept this setting passed via Docker env-variable.
docker/swagger/docker-compose.yml:

version: '3.8'

services:
  swagger-full:
    environment:
      URLS: "[
      { url: \"swagger/internal.yaml\", name: \"Internal\" }
    ]"
      DOC_EXPANSION: 'none'
      DEFAULT_MODEL_RENDERING: 'model'
      DEEP_LINKING: 'true'
      BASE_URL: "/swagger-full"
    image: ${REPO_PREFIX}/swagger-full:${CI_COMMIT_REF_SLUG}
    logging:
      driver: json-file
      options:
        max-size: 16m
        max-file: "16"
    networks:
      - basenet
    ports:
      - 18081:8080
    restart: unless-stopped

networks:
  basenet:
    external: true

I doubt this file makes sense for this issue - but nevertheless, here it is:
docker/swagger/config.yaml:

# In this file, you can set the correspondence of swagger files to environments (dev/prod)
# It is the source of the truth:
# - To build swagger
# - For deployment env with swagger

# This is a list of files where name is also the dst name after the build.
files:
  - name: internal
    src: internal/v1/swagger.yaml

# Mapping files by environments.
envs:
  full:
    - internal
  dev:
    - internal

Expected behavior: When I open Swagger UI, I get my api specification fully loaded, $ref fully resolved.
Real behavior: When I open Swagger UI, I see the list with my methods (that's ok) - but all $ref resolved to smartbear.com host, though with correct uri behind the wrong host. For the mentioned above internal API, I see this 403 error in my browser console: https://smartbear.com/ready/responses/ready-response.json.

Additional context
By the way, this installation is perfectly working now with previous minor version of OpenApi 3.0.2. The installation and config files are totally the same - and it works, so I don't unserstand why for OpenApi 3.1.0 it looks like I missed to pass BASE_URL env-variable.
As I've mentioned in the original comment, I tried to override this behavior by all means (including setting servers at the root of swagger.yaml, as well as by packing all $ref into components/schemas) - it didn't help.
I am trying to switch to OpenApi 3.1.0 for brilliant feature of supporting type: "null".

[PatchRanger]

I've workarounded it by setting absolute URLs to urls config setting. It now looks like this in docker-compose.yml:

version: '3.8'

services:
  swagger-full:
    environment:
      URLS: "[
      { url: \"http://example.com/swagger-full/swagger/internal.yaml\", name: \"Internal\" }
    ]"
      BASE_URL: "/swagger-full"
    ...

Looks like the reason of this bug is that OpenApi 3.1 can't resolve relative urls passed by urls config setting: it misses handling of BASE_URL passed with URLS.
For now I have another problem though. I am going to create another issue for it.

[char0n]

HI @PatchRanger,

Thank for the additional info.

BASE_URL is not related to definition resolution. Here is an excerpt from the documentation what it does:

To say it simply, it's a way to influence how docker nginx serve the SwaggerUI - under which URL.

---

Having said that, I've dug deep and found out the original issue.

You used relative URLS in URLS env variable:

      URLS: "[
      { url: \"swagger/internal.yaml\", name: \"Internal\" }
    ]"

More idiomatic way how to achieve the same result is SWAGGER_JSON env var. Both env variables will result in the same bug tough. The bug is actually related to the fact that the relative URL is provided to swagger-client for resolution. OpenAPI 3.1.0 requires absolute retrievalURL to actually perform the resolution.

I'll create a bug fix in upstream is swagger-client to make sure that we handle the case of relative URLs passed as retrieval URL.

I could reproduce with following command:

$ docker run -p 80:8080 -e BASE_URL=/swagger -e SWAGGER_JSON=/foo/schemas/internal/v1/swagger.yaml -v /home/char0n/Documents/GitHub/swagger-ui:/foo swagger-api/swagger-ui

[char0n]

Addressed upstream in swagger-api/swagger-js#2905