block / block/buzz

[Bug] deploy/compose: default BUZZ_CORS_ORIGINS omits Tauri webview origins — desktop "Join an existing community" fails with "Load failed"

Open
#2,872 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
32.7k
Forks
4.3k
Avg merge
1d 13h
Merged PRs (30d)
253

Description

## Summary

A relay deployed from the `deploy/compose` template blocks the desktop app at CORS preflight. The template ships

```
BUZZ_CORS_ORIGINS=https://buzz.example.com
```

(operators substitute their own domain), but the desktop app's WebView runs from origin `tauri://localhost` (macOS/Linux) or `http://tauri.localhost` (Windows). Since neither is in the allowlist, the WebView's HTTP API calls to the relay are rejected, and "Join an existing community" fails with WebKit's generic `Load failed`.

What makes this confusing to debug: `curl` and NIP-11 checks against the same relay succeed, so the relay looks perfectly healthy from everywhere except the app.

## Environment

- Buzz Desktop v0.4.26 (macOS)
- Relay `ghcr.io/block/buzz@sha256:77e1c6b1…`, self-hosted via `deploy/compose` with Caddy TLS

## Steps to reproduce

1. Fresh `deploy/compose` deployment: copy `.env.example` → `.env`, set `BUZZ_CORS_ORIGINS=https://` per the template.
2. Desktop app → Add community → Join an existing community → enter the relay URL.
3. Join fails with `Load failed`.
4. `curl -H 'Accept: application/nostr+json' https://` returns the NIP-11 document fine.

## Cause

The relay parses `BUZZ_CORS_ORIGINS` as a comma-separated list of exact origins (`crates/buzz-relay/src/config.rs`) and `build_cors_layer` in `crates/buzz-relay/src/router.rs` deliberately does not fall back to permissive CORS when the variable is set. That behavior is sensible — the problem is only that the compose template's default value omits the desktop origins, so every self-hosted deployment configured from it breaks the desktop app.

## Suggested fix

Include the desktop origins in the template default:

```
BUZZ_CORS_ORIGINS=https://buzz.example.com,tauri://localhost,http://tauri.localhost
```

and add a short note to `deploy/compose/README.md` (currently silent on CORS) that the Tauri origins must stay in the allowlist for the desktop app to work against a self-hosted relay.

Verified on the deployment above: adding those two origins and restarting the relay resolves the join failure.

## Related (not duplicates)

- #2617 documents `BUZZ_CORS_ORIGINS` + the Tauri origins, but in the root `.env.example` — the value shipped by `deploy/compose/.env.example` is unchanged.
- #2862 moves the join-policy fetch to native networking, which would bypass CORS for direct relay-URL joins — but other WebView HTTP calls (e.g. invite minting/redemption, moderation) still need these origins allowlisted, so the compose default remains a footgun even after it lands.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.