livebook: Error on Kino script loading if a livebook instance is behind cookie based authentication proxy

Environment

Elixir & Erlang/OTP versions (elixir --version):
Operating system:
How have you started Livebook (mix phx.server, livebook CLI, Docker, etc): Docker
Livebook version (use git rev-parse HEAD if running with mix): livebook/livebook@sha256:4623d37ca4d4ac7d06a48a12d0745e02c301abb42baac2674d0a1771f0dc5be7
Browsers that reproduce this bug (the more the merrier): Google Chrome 97.0.4692.71
Include what is logged in the browser console:
Include what is logged to the server console:

Current behavior

Step to reproduce

Open Cloud Shell on GCP console
docker run -p 8080:8080 --pull always livebook/livebook:edge
Open Web Preview and pass the generated token
Open the “Introduction to Kino” notebook and run Kino.DataTable section

Without GCP: https://github.com/en30/livebook-issue-954

Result

DataTable widget does not show up.

Error message in the browser console: Access to script at '*/main.js' from origin 'null' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

The HTTP request does not include Cookie header and the response redirects to an authentication page that is of a different origin in this case.

Expected behavior

DataTable widget shows up if possible.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 22 (22 by maintainers)

Most upvoted comments

@jonatanklosko Thank you for addressing the issue. And thank you for all of your hard work and the great product.

en30 on Feb 3, 2022

Using service workers is likely asking for trouble. We would need to proxy the request as sw -> iframe -> livebook -> iframe -> sw. But even then I don’t think it’s possible, because passing objects, such as Request as messages is not possible (results in an error like “object cannot be cloned”). For the request specifically maybe we could do manual serialization and recreation, however for response I’m not so sure. Either way, I think this would be an overkill complexity-wise.

jonatanklosko on Feb 3, 2022

@jonatanklosko

in your use case, how hard would it be to expose /public/* without auth?

For Cloud Shell’s Web Preview (the original use case of this PR) which launches an authentication proxy implicitly, I could not find a way to configure passthrough paths.
For Google Cloud’s Identity-Aware Proxy, a managed authentication proxy service, there is a way to configure passthrough paths

I think the solution is reasonable. At least there are ways to work around this issue.

en30 on Feb 3, 2022