This issue attempts to summarize a discussion I had with @bryevdv about overhauling session expiry and provide a token containing a variety of information. The issue with the current mechanism for providing a signed sessions is that it is encoded as part of the Websocket URL which means that it ends up in logs and risks being leaked. Since session ids also never expire this adds additional risks because the other flaw can effectively be exploited until the server is restarted or shut down. Therefore we would like to overhaul both the mechanism by which the token is transmitted and add an expiration to it. This would be done by providing a JWT token to the client which it uses to authenticate itself. This token would then be transmitted using the Websocket subprotocol header.
The JWT token can additionally be used to transmit various information about the original request. One other problem with the bokeh server today is that when running behind a load balancer there is no way to access information about the request such as headers or cookies when the HTTP request and the Websocket connection arrive on different processes. The JWT token could therefore also be used to serialize a variety of information which can then be made available from the session on curdoc().session_context. By default the following should be made available:
- Session ID
- Token
- Token Valid From time
- Token Expiry Time
- Authenticated User
We could then consider adding the entire request or providing a mechanism by which a user defines what should be made available, e.g. by providing a function which is given the request and returns a JSON serializable dictionary.
This issue attempts to summarize a discussion I had with @bryevdv about overhauling session expiry and provide a token containing a variety of information. The issue with the current mechanism for providing a signed sessions is that it is encoded as part of the Websocket URL which means that it ends up in logs and risks being leaked. Since session ids also never expire this adds additional risks because the other flaw can effectively be exploited until the server is restarted or shut down. Therefore we would like to overhaul both the mechanism by which the token is transmitted and add an expiration to it. This would be done by providing a JWT token to the client which it uses to authenticate itself. This token would then be transmitted using the Websocket subprotocol header.
The JWT token can additionally be used to transmit various information about the original request. One other problem with the bokeh server today is that when running behind a load balancer there is no way to access information about the request such as headers or cookies when the HTTP request and the Websocket connection arrive on different processes. The JWT token could therefore also be used to serialize a variety of information which can then be made available from the session on
curdoc().session_context. By default the following should be made available:We could then consider adding the entire request or providing a mechanism by which a user defines what should be made available, e.g. by providing a function which is given the request and returns a JSON serializable dictionary.