Skip to content

Addresses of their own#

The IDE of an IDE environment, and every app you run in a runtime — TensorBoard, Streamlit, Gradio, Spark's UI — open in your browser at an address of their own, not at the console's:

What Its address
An environment's IDE https://r-<id>.<domain>/
An app on port <port> of a runtime https://r-<id>-<port>.<domain>/

<id> is a random identifier of the runtime (20 hexadecimal characters) that names nothing; <domain> is Astralyx's domain for runtimes.

Why not the console's address#

A page a runtime serves is code chosen by whoever controls the container: its owner, or anything running in it. Served at the console's address, it would run in the console's origin, with your console session — able to read your workspaces and act as you. Someone who shares an environment with you could hand you a page that does exactly that. At an address of its own, the page is in a different origin: it cannot read the console's session, and the console does not trust it.

The notebook editor is different: it is the console's own code, which speaks Jupyter's protocol and shows outputs as data. HTML outputs are shown in sandboxed frames with no origin, and files of the drive opened at their address are served as documents that cannot run script. So a notebook stays at the console's address, and its Jupyter is every editor's of the workspace.

Getting there#

  1. You press Open IDE or an app's Open in the console, or run astra env open or astra env port.
  2. Astralyx checks that you may use the runtime — its owner, one of its members, or a workspace admin — and that it is on a machine, and gives you a single-use link to its address. The link works once, within a minute, for you, at that address only.
  3. Your browser follows it and receives a cookie for that address only — HttpOnly, host-only, Secure, valid 8 hours. It then lands on the IDE (in its folder) or the app.

After 8 hours, press Open IDE or Open again for a new one. The link astra env port --print prints is the same single-use link: open it within a minute, once.

Every request is checked again#

At the runtime's address, the cookie is the only credential accepted. For every request and WebSocket, Astralyx checks again:

  • your session at that address: this runtime, this port, not expired;
  • your access to the workspace now: someone taken out of the workspace is refused at once;
  • the runtime's rule: someone taken off its members is refused from their next request.

Then the request goes over the machine's own connection to the port inside the container. The machine connects to it on the container's own network, so an app listening on 127.0.0.1 is enough, and nothing is opened on the machine.

What a page there can and cannot do#

  • No cookies reach the app, and an app's own Set-Cookie never reaches your browser. An app that needs cookies — Streamlit's upload protection, an app with its own login — must run without them: start Streamlit with --server.enableXsrfProtection false.
  • Not in a frame of another site, and no cross-origin requests: an app's own CORS headers are dropped, and a request or WebSocket from another address is refused.
  • Its own ports only. Any port of the container is an app, except the runtime's own servers: SSH's 2222, a notebook runtime's Jupyter 8888, an IDE's 8822.

Who may open them#

The same people who may SSH into the runtime: its owner, the people it is shared with, the workspace's admins. Another editor of the workspace is refused a link (403 SSH_FORBIDDEN) and, at the address, every request (403 IDE_FORBIDDEN for an IDE, 403 APP_FORBIDDEN for an app); viewers reach nothing. An IDE's terminals are a shell in the container, and an app runs as the container does, so they are SSH's to give. This holds for notebooks' runtimes too: a notebook's apps are its runtime owner's (and members' and admins'), even though its Jupyter is every editor's.