Setup and CORS

bee-check-web is a static SPA hosted at ethswarm-tools.github.io/bee-check-web. It probes Bee nodes directly from your browser — there is no hosted backend. That keeps the operational surface tiny but means your Bee node has to be reachable from the browser, which raises two real-world snags:

1. CORS — your Bee must explicitly allow the SPA’s origin.
2. HTTPS / mixed-content — a page served over HTTPS can’t call plain http://... URLs (with one exception: http://localhost).

This chapter covers both.

CORS

Set this in your Bee config (typically ~/.bee/bee.yaml):

cors-allowed-origins:
  - https://ethswarm-tools.github.io
  # For local dev with `npm run dev`:
  - http://localhost:5173

Then restart Bee. Verify with:

curl -i -X OPTIONS \
     -H "Origin: https://ethswarm-tools.github.io" \
     -H "Access-Control-Request-Method: GET" \
     http://your-bee:1633/addresses

You should see an Access-Control-Allow-Origin: https://ethswarm-tools.github.io header in the response.

If you don’t add CORS, the SPA’s probe will return error for that vantage and the browser console will show a CORS rejection.

HTTPS / mixed-content

The deployed SPA is served over HTTPS. Modern browsers refuse to let an HTTPS page call http://1.2.3.4:1633 — that’s mixed-content blocking, and there’s no override flag in normal browser settings.

Your options:

• Point the SPA at http://localhost:1633 — localhost is exempt from the mixed-content rule.
• Front your Bee with a TLS reverse proxy (Caddy, nginx, Cloudflare Tunnel, etc.) and point at the HTTPS URL.
• Run the SPA locally (npm run dev → http://localhost:5173) if you want everything on HTTP.

A mixed-content rejection shows up the same way as a CORS one: the vantage returns error, and the console explains.

Verifying both work

The easiest sanity check is to load the SPA, paste your Bee URL, leave the reference field empty, and click anywhere. If the form accepts your Bee URL and you can see a 200 in the browser network tab for GET /addresses, you’re set.