If I understand correctly, --allow-websocket-origin controls which origins can access the page. In my case that would mean that I could only access the page from the device that is hosting the server (same IP/port).
However I am also able to access the page from other devices (with different IPs) within the same local network.
The ORIGIN is what is in the browser URL bar, more or less. If your Bokeh server app is deployed at 192.168.2.111:8082 and users (anywhere) navigate to 192.168.2.111:8082 in their browser, then the ORIGIN is for the request is 192.168.2.111:8082 and the connection is allowed (as expected).
--allow-websocket-origin is only relevant to prevent unwanted embedding. I.e. if you use server_document to embed your app in a page you host at foo.com and set --allow-websocket-origin=foo.com, then when users navigate to foo.com the ORIGIN is foo.com, which is allowed, and the connection is allowed. But if some other third party tried to embed your app in their page at bar.com then that would fail because bar.com is not an allowed origin.
TLDR; --allow-websocket-origin is to prevent other people from embedding your app in their page without your consent. I.e. --allow-websocket-origin is not an authentication or access mechanism, it is more like a CORS specification for websockets. And it’s needed to be provided by us because standard websockets do not actually have anything like a CORS specifcation at all, they are just wide open.
it sounds like what you are actually interested in is authentication and access. There’s various different approaches you can look at for that. Bokeh server exposes “auth hooks” that you can use to accept or reject connections. That’s usually imagined as credentials-based, but I suppose you could implement a hook that rejects based on the request source address. Alternatively, you can put the Bokeh server behind a reverse proxy e.g. Nginx for things like this.