Closed parente closed 8 years ago
FYI, the websocket client we're using supports custom headers on connect (https://github.com/theturtle32/WebSocket-Node/blob/master/docs/WebSocketClient.md#connectrequesturl-requestedprotocols-origin-headers-requestoptions) which I think we're already using for the optional KG API key. And the node-http-proxy lib does too if I recall.
Regarding the two options outlined in the description: we an either ask the sysadmin to set an headers object in config.json or create a JS file with a function which returns the same object? Unless I'm missing something, the former seems much easier to me.
Agreed. Latter would be if the property has to be computed dynamically, say for a service, where the service implementer would be the one writing the module.
The former sounds like the right first step. Module approach could be added later if needed.
Was wondering if it would make sense to change prop name from AJAX_SETTINGS
to PROXY_SETTINGS
.
@jhpedemonte Yea, that probably makes more sense. You can send another PR with it.
A common pattern for securing access to one or more kernel gateways is to use a proxy server. For instance, an nginx proxy might have routes to multiple instances and secure them with different username/password combos. (See https://github.com/jupyter/kernel_gateway_demos/pull/24) As another example, the proxy might require auth headers other than the one supported by the kernel gateway (e.g., X-Instance).
To work with these setups, the dashboard server needs to support setting configurable headers when proxying HTTP or websocket connections. This could be implemented in a couple of ways. (Supporting one way is enough).
The former is probably enough for now, unless we thinking dynamic headers should be supported right off the bat.