Support basic auth and/or custom headers when proxying to a kernel gateway

[parente]

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).

• Reading an object from the config with header key/value pairs
• Supporting a module system like we did with auth to plug-in in an arbitrary JS function that returns an object with header key/value pairs on each request

The former is probably enough for now, unless we thinking dynamic headers should be supported right off the bat.

[parente]

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.

[jhpedemonte]

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.

[parente]

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.

[jhpedemonte]

Was wondering if it would make sense to change prop name from AJAX_SETTINGS to PROXY_SETTINGS.

[parente]

@jhpedemonte Yea, that probably makes more sense. You can send another PR with it.