New Feature - Carry client ip over bokeh session

Hello,

The goal would be to have access to the ip of the client connecting to the bokeh server, so that to display adapted/differentiated content based on the ip of the client and/or log the activity.

One very simple example about client activity is that at one point in time, to my knowledge there is no way to know who is connected to the server through the bokeh app framework. You do have in the logs the “GET” request showing the IP at the connection phase, but you don’t get to know who is disconnecting, and therefore who is still there.

However, unfortunately, looking at the documentation (Running a Bokeh server — Bokeh 2.4.2 Documentation) It seems only the request arguments are available.

Diving in the code (server/application_context.py), it’s practically done by creating a _RequestProxy(request) which mirrors the initial request object, dropping all but the arguments.

Adding to the proxy through the remote_ip field seems to do the job from what I see.

Would passing the ip through indeed create some incompatibility issues ? or is the documentation warning not applying to the ip and in that case could this feature be added to future bokeh release ?

Thanks in advance,

Damien

Hi,

Yes, there is unfortunately a bad incompatibility with accessing the real HTTP request whenever "--num-procs" is not 1, or whenever running a Bokeh server behind a load balancers. You can see a full discussion here:

  https://github.com/bokeh/bokeh/issues/5582

The gist of the problem is that the first process that services the initial HTTP request is not guaranteed to be the same process that handles the subsequent web socket upgrade. In this event, the request is None and any attempt to access it results in a runtime exception.

We were able to keep the request args functionality by somewhat hackily encoding them in the web socket URL, so that the process that handles the webscocket can access them, and expose them via the _RequestProxy. I'm not sure I'd want to extend this ad-hoc solution any further, however, especially to things that are not already normally visible in URL strings.

What might be possible to consider would be to add user-accessible hooks for encoding/decoding extra things in the WS URL. Basically I definitely would want to kick the can down the road and make users be responsible for specifying exactly how to encode any additional information, because there are sure to be different tolerances what is acceptable to transmit in webscocket URLs. This would represent new development, however, so the next appropriate step would be a GH feature request issue.

Thanks,

Bryan