-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: rest explorer now hosts its own copy of oas by default #3133
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -52,6 +52,77 @@ requesting a configuration option for customizing the visual style, please | ||||||||||
up-vote the issue and/or join the discussion if you are interested in this | |||||||||||
feature._ | |||||||||||
|
|||||||||||
### Advanced Configuration and Reverse Proxies | |||||||||||
|
|||||||||||
By default, the component will add an additional OpenAPI spec endpoint, in the | |||||||||||
format it needs, at a fixed relative path to that of the Explorer itself. For | |||||||||||
example, in the default configuration, it will expose `/explorer/openapi.json`, | |||||||||||
or in the examples above with the Explorer path configured, it would expose | |||||||||||
`/openapi/ui/openapi.json`. This is to allow it to use a fixed relative path to | |||||||||||
load the spec, to be tolerant of running behind reverse proxies. | |||||||||||
|
|||||||||||
You may turn off this behavior in the component configuration, for example: | |||||||||||
|
|||||||||||
```ts | |||||||||||
this.configure(RestExplorerBindings.COMPONENT).to({ | |||||||||||
useSelfHostedSpec: false, | |||||||||||
}); | |||||||||||
``` | |||||||||||
|
|||||||||||
If you do so, it will try to locate an existing configured OpenAPI spec endpoint | |||||||||||
of the required form in the REST Server configuration. This may be problematic | |||||||||||
when operating behind a reverse proxy that inserts a path prefix. | |||||||||||
|
|||||||||||
When operating behind a reverse proxy that does path changes, such as inserting | |||||||||||
a prefix on the path, using the default behavior for `useSelfHostedSpec` is the | |||||||||||
simplest option, but is not sufficient to have a functioning Explorer. You will | |||||||||||
also need to explicitly configure `rest.openApiSpec.servers` (in your | |||||||||||
application configuration object) to have an entry that has the correct host and | |||||||||||
path as seen by the _client_ browser. | |||||||||||
|
|||||||||||
Note that in this scenario, setting `rest.openApiSpec.setServersFromRequest` is | |||||||||||
not recommended, as it will cause the path information to be lost, as the | |||||||||||
standards for HTTP reverse proxies only provide means to tell the proxied server | |||||||||||
(your app) about the _hostname_ used for the original request, not the full | |||||||||||
original _path_. | |||||||||||
|
|||||||||||
Note also that you cannot use a url-relative path for the `servers` entry, as | |||||||||||
the Swagger UI does not support that (yet). You may use a _host_-relative path | |||||||||||
however. | |||||||||||
|
|||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To make it easy to understand, maybe we should build a table to show different cases with corresponding configurations, such as:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 will work on that I think the scenarios to consider are:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd like to add to more well-known cases to the list:
|
|||||||||||
#### Summary | |||||||||||
|
|||||||||||
For some common scenarios, here are recommended configurations to have the | |||||||||||
explorer working properly. Note that these are not the _only_ configurations | |||||||||||
that will work reliably, they are just the _simplest_ ones to setup. | |||||||||||
|
|||||||||||
| Scenario | `useSelfHostedSpec` | `setServersFromRequest` | `servers` | | |||||||||||
| ----------------------------------------------------------------------------------- | ------------------- | -------------------------------------- | ---------------------------------------------------------------- | | |||||||||||
| App exposed directly | yes | either | automatic | | |||||||||||
| App behind simple reverse proxy | yes | yes | automatic | | |||||||||||
| App exposed directly or behind simple proxy, with a `basePath` set | yes | yes | automatic | | |||||||||||
| App exposed directly or behind simple proxy, mounted inside another express app | yes | yes | automatic | | |||||||||||
| App behind path-modifying reverse proxy, modifications known to app<sup>1</sup> | yes | no | configure manually as host-relative path, as clients will see it | | |||||||||||
| App behind path-modifying reverse proxy, modifications not known to app<sup>2</sup> | ? | ? | ? | | |||||||||||
| App uses custom OpenAPI spec instead of LB4-generated one | no | depends on reverse-proxy configuration | depends on reverse-proxy configuration | | |||||||||||
|
|||||||||||
<sup>1</sup> The modifications need to be known to the app at build or startup | |||||||||||
time so that you can manually configure the `servers` list. For example, if you | |||||||||||
know that your reverse proxy is going to expose the root of your app at | |||||||||||
`/foo/bar/`, then you would set the first of your `servers` entries to | |||||||||||
`/foo/bar`. This scenario also cases where the app is using a `basePath` or is | |||||||||||
mounted inside another express app, with this same reverse proxy setup. In those | |||||||||||
cases the manually configured `servers` entry will need to account for the path | |||||||||||
prefixes the `basePath` or express embedding adds in addition to what the | |||||||||||
reverse proxy does. | |||||||||||
|
|||||||||||
<sup>2</sup> Due to limitations in the OpenAPI spec and what information is | |||||||||||
provided by the reverse proxy to the app, this is a scenario without a clear | |||||||||||
standards-based means of getting a working explorer. A custom solution would be | |||||||||||
needed in this situation, such as passing a non-standard header from your | |||||||||||
reverse proxy to tell the app the external path, and custom code in your app to | |||||||||||
make the app and explorer aware of this. | |||||||||||
|
|||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nice 👍 |
|||||||||||
## Contributions | |||||||||||
|
|||||||||||
- [Guidelines](https://github.com/strongloop/loopback-next/blob/master/docs/CONTRIBUTING.md) | |||||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it disable the spec endpoints exposed by
@loopback/rest
if the explorer component has its own?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it leaves those un-touched