DapperDox can proxy URL paths to other services. This allows multiple services to be accessed from the same domain as DapperDox, such as user API key management, user sign-on, and services to provide API keys and other credentials to DapperDox's API explorer.
The exposed path, for example /forum/some-page
, is passed through to the proxied service,
therefore the service must be configured to recognise and respond to that path. DapperDox
does not rewrite requests or response pages.
A reverse proxy configuration for DapperDox consist of two parts.
These are supplied to DapperDox through the -proxy-path
configuration option, which takes
the form
-proxy-path=source-path=service-host/destination-path/
If the proxied host declaration contains the optional
/destination-path/
then that path will prefix the source path in the forwarded request, becoming/destination-path/source-path
.
Multiple proxy configurations can be supplied to DapperDox, by repeating the
-proxy-path
configuration option (or comma separating the values if you are using
environment variables for configuration).
The configuration for the above example would be:
-proxy-path=/user/sign-on/=https://192.168.10.1 \
-proxy-path=/forum/=https://192.168.10.2 \
-proxy-path=/applications/=https://192.168.10.3
or with environment variables:
export PROXY_PATH=/user/sign-on/=https://192.168.10.1,/forum/=https://192.168.10.2,/applications/=https://192.168.10.3
DapperDox can proxy between HTTP
and HTTPS
connections, or vice versa.
However, care should be taken to avoid mixed content issues when
DapperDox is configured to serve content over HTTPS
and you are proxying to an HTTP
service.
Once a path is forwarded, DapperDox hands all response generation onto the proxied service.
This means that all responses generated by the service, including 404 Page not found
,
are passed back to the client untouched.