Description
Is your feature request related to a problem? Please describe.
When using the actuator support the OpenAPI definition and SwaggerUI pieces are hinted at to be available via the actuators openapi
and swaggerui
, resulting in the following paths:
http://localhost:8081/actuator/openapi/
http://localhost:8081/actuator/swaggerui/
A special case is described when springdoc.use-management-port
is undefined or set to false. However, in case it is set to true I would expect that these two APIs are the only ones I actually need. The reality is that calling http://localhost:8081/actuator/swaggerui/
will redirect to http://localhost:8081/actuator/swagger-ui/index.html
– which is an altogether different path. There doesn't appear to be a way to serve everything from the swaggerui
actuator endpoint, not even when using the rewrite directives (springdoc.swagger-ui.path
and springdoc.webjars.prefix
).
The following two spring profiles behave exactly the same:
management:
endpoints:
enabled-by-default: true
web:
exposure:
include: ["openapi", "swaggerui"]
server:
port: 8081
---
spring:
config:
activate:
on-profile: default-behavior
springdoc:
show-actuator: true
api-docs:
enabled: true
swagger-ui:
enabled: true
disable-swagger-default-url: true
validatorUrl: null
use-management-port: true
---
spring:
config:
activate:
on-profile: rewrite-behavior
springdoc:
show-actuator: true
api-docs:
enabled: true
path: /swaggerui/swagger.json
swagger-ui:
enabled: true
path: /swaggerui
disable-swagger-default-url: true
validatorUrl: null
webjars:
prefix: /swaggerui/webjars
use-management-port: true
Describe the solution you'd like
I would like better documentation for the interaction between path
properties and use-management-port
/ show-actuator
/ management.endpoints.web.exposure.include
. Additionally, I would prefer if no unexpected redirect to /swagger-ui
were to happen and instead I can freely chose the actuator sub-path where the UI is offered – if possible defaulting to swaggerui
.
Additional context
This question arises because when dealing with WebSecurityConfigs and (dis)allowing access to paths via e.g. ant-style matcher syntax the redirect to a third path complicates matters somewhat.