@yoshipon: you correctly mentioned in #267 (comment) on a suggestion form @jdhayes that --path_prefix itself is still insecure on a multi-user system; I hope you like the new approach in this PR to read the hash from a file :-)

We believe the comment #267 (comment) is still governing on changes/features requests along these lines.

We believe the comment #267 (comment) is still governing on changes/features requests along these lines.

you cannot easily start NGiNX on a multi-user HPC system - can you? And even if you can it does not solve the problem at akk as NGINX and Tensorboard are still running on multiuser system exposing Tensorboard at least locally

We are facing a similar issue at our HPC center. This is already a good step forward to run TensorBoard on multi-user environment. Is it possible to use the approach of JupyterLab here by providing the path prefix as a token and user needs that token to access TensorBoard?

Yes, I agree. HPC facilities cannot use NGINX, as the localhost is still exposed to all users on the node. Just a note, that if anyone was going to make it as a service, then NGINX would be a good option to add real authentication.

The Jupyter hash/token is a good method for HPC facilities to obscure the URL such that users do not accidentally intrude. Malicious users are less of an issue, but even they would have difficulty finding the address if a hash/token was added.

If reading from a file is not acceptable, could the --path_prefix take the value from an environment variables if not provided on the command line?

Yes, I agree. HPC facilities cannot use NGINX, as the localhost is still exposed to all users on the node. Just a note, that if anyone was going to make it as a service, then NGINX would be a good option to add real authentication.

The Jupyter hash/token is a good method for HPC facilities to obscure the URL such that users do not accidentally intrude. Malicious users are less of an issue, but even they would have difficulty finding the address if a hash/token was added.

If reading from a file is not acceptable, could the --path_prefix take the value from an environment variables if not provided on the command line?

Please have a look at #5570

I close this request for now.
#5570 seems th be the superior solution to the security problem.
Feel free to reopen if you think this option is still needed/usefull