# Web Endpoint

Opens a host's web UI from Termix, either directly or through an SSH tunnel, in an
embedded tab or an isolated desktop window.

Each host can define up to 16 endpoints (`MAX_WEB_ENDPOINTS`). An endpoint is either:

- **direct** — the browser loads `scheme://host:port/path` itself, or
- **tunnel** — the backend opens a local SSH forward to the target port and the frame
  loads it over loopback.

## Layout

| Path                                  | What it is                                                             |
| ------------------------------------- | ---------------------------------------------------------------------- |
| `backend/index.mjs`                   | Plugin entry: `activate` starts the service, `deactivate` stops it.    |
| `backend/routes.ts`                   | `POST /open` — opens or reuses the forward and returns the bound port. |
| `frontend/WebEndpointTab.tsx`         | The embedded viewer (a `credentialless` sandboxed iframe).             |
| `frontend/web-endpoint-api.ts`        | Client for the open route plus the Electron bridges.                   |
| `frontend/web-endpoint-url.ts`        | URL building and the cookie/reachability refusal rules.                |
| `frontend/web-endpoint-validation.ts` | Editor-side mirror of the backend normalizer.                          |

## What stays in core

This plugin owns its lifecycle, not all of its code. Three pieces deliberately stay in
Termix proper:

- **`host-web-endpoints.ts`** (`src/backend/database/routes/`). Despite sitting in
  `routes/` it has no router — it is the `webUiConfig` normalizer, imported by `host.ts`,
  `host-bulk-routes.ts` and `host-normalizers.ts` to sanitize the column on every host
  save and list. Disabling this plugin must not stop that validation, and core cannot
  import plugin code in any case.
- **The Electron half** (`electron/web-endpoint-window.cjs` plus the
  `open-isolated-web-endpoint` and `allow-invalid-certificate-for-origin` handlers in
  `main.cjs`). `BrowserWindow` and `session` are main-process-only, the renderer is what
  invokes those channels, and the main process loads no plugin code today.
- **`HostEditorWebUiSection.tsx`** (`src/ui/sidebar/`). It is a section inside the host
  editor's General tab and takes the core-owned `{ form, setField }` pair, the same
  reason docker leaves `HostDockerTab` in core.

The `enableWebUi` and `webUiConfig` columns stay on core's `ssh_data` table, declared
here through `contributes.hostCapability`.

## Tunnels

A tunnel endpoint opens through the tunnels plugin, a hard dependency. `POST /open`
calls `forward()` on its `tunnels.access` service, which connects through core's SSH
pipeline, binds the local listener, probes the target once and only then returns the
bound port. The forward runs under the reserved `web:<hostId>:<endpointId>` name, so
the tunnels plugin never retries it and closes it after ten idle minutes.

## Routing

Core mounts the route at `/plugin-api/web-endpoint/open` through `ctx.http.router()`,
which the generic `/plugin-api/` block in both nginx configs already proxies.

## Tests

Backend tests are in `src/backend/tests/plugins/web-endpoint/` (the backend vitest
project only globs `src/backend/**`). Frontend tests sit beside the source here, which
the frontend project picks up via `plugins/**/frontend/**/*.test.{ts,tsx}`.

`web-endpoint-validation.test.ts` deliberately imports the backend normalizer as well as
the editor one and runs both over the same samples, so the two implementations cannot
drift.