clusterfuck
/
crabidy
4
1
Fork 0
Code Issues 15 Pull Requests Actions Packages Projects 1 Releases 5 Wiki Activity
crabidy/cbd-web
History
Test User 659e678522 Web client: prompt for login on visit when auth is enabled 
The browser client already sent stored credentials and showed a login
form, but only when the server answered UNAUTHENTICATED -- i.e. only
when every role was guarded. With a fallback role configured, an
anonymous browser silently connected as that role and was never offered
a way to log in as a higher one.

The server now reports its auth on/off switch on the InitResponse
(auth_enabled, field 8), which is reachable anonymously. The RPC handler
stamps it from Authenticator::enabled(); the playback loop, which owns
queue state and not the auth config, leaves it false.

On first connect with no stored credentials against an auth-enabled
server, the web client raises the login dialog. It is dismissible --
"continue as guest" keeps the unauthenticated fallback role -- and is
shown once per session so stream reconnects do not nag. When the server
denies anonymous access outright (UNAUTHENTICATED), the same dialog
appears without the guest option, because credentials are then the only
way in.

Docs: architecture/roles-auth.md and web-client.md updated.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 		2026-07-23 17:51:55 +02:00
..
src Web client: prompt for login on visit when auth is enabled 2026-07-23 17:51:55 +02:00
.gitignore Add a Leptos web client served by the server 2026-07-21 22:43:06 +02:00
Cargo.toml Add a Leptos web client served by the server 2026-07-21 22:43:06 +02:00
README.md Add a Leptos web client served by the server 2026-07-21 22:43:06 +02:00
Trunk.toml Add a Leptos web client served by the server 2026-07-21 22:43:06 +02:00
index.html Add a Leptos web client served by the server 2026-07-21 22:43:06 +02:00
style.css Add a server-streamed frequency spectrum visualizer 2026-07-21 23:14:03 +02:00

README.md

cbd-web — the browser client

A Leptos client-side WASM app with the same functionality as cbd-tui, served by crabidy-server itself. See architecture/web-client.md for the design.

How it works

  • Transport: gRPC-web (tonic-web-wasm-client) over the same generated client and proto types the TUI uses (crabidy-core). No second API surface — feature parity is structural. The server wraps its existing gRPC service in tonic-web, so the browser and the TUI hit identical /crabidy.v1.CrabidyService/… paths, and the role auth layer (architecture/roles-auth.md) gates both.
  • Serving: the built bundle (cbd-web/dist) is embedded into crabidy-server at compile time behind the default-on web-ui feature and served as the fallback route on port 50051. gRPC and static assets share one origin, so there is no CORS story.
  • Local-first: pure client-side rendering, every asset in the bundle (no CDN, no external fonts), library listings cached in memory like the TUI, credentials and theme in localStorage, and the update stream reconnects with backoff when the server disappears. There is no CRDT layer — this is a remote control for one live server state, not an offline-editing app (a deliberate departure from the web_client_example_workspace template that informed the toolchain).

Functionality

Everything the TUI does: browse the library (j/k/h/l, click), marks, create/rename/delete nodes (%/e/d, with the capture-delete y/N confirmation), bookmark and capture (w/W, with live progress lines and skipped-track marking), the full queue and playback controls, volume, shuffle/repeat, and a ? help overlay listing the keys. Keys mirror the TUI; every key also has a clickable control. A light/dark theme follows the OS and can be toggled (persisted). The accent color is the crab orange-red.

When the server requires credentials, a login form collects the role (owner / queue-owner / queue-appender) and password; they are stored in localStorage and sent as the gRPC-web authorization header on every request.

Building

The WASM toolchain (trunk, wasm-bindgen, the wasm32-unknown-unknown target) is provided by devenv. From the repo root:

devenv shell -- build-web        # release bundle → cbd-web/dist
cargo build -p crabidy-server    # embeds cbd-web/dist

build-web clears RUSTFLAGS first: the native toolchain sets the mold linker, which rust-lld (the wasm linker) cannot parse.

Building crabidy-server without a cbd-web/dist present is fine — it embeds a placeholder page telling you to run build-web. Build the server --no-default-features to drop the web client (and the tonic-web layer) entirely.

Dev loop

Run a server, then a live-reloading trunk server that proxies gRPC-web to it:

cargo run -p crabidy-server      # or `cbd`
devenv shell -- serve-web        # trunk serve on http://127.0.0.1:8080

Trunk.toml proxies /crabidy.v1.CrabidyService to 127.0.0.1:50051, so the app behaves as if served from the server.

Tests

The DOM-free logic (pane/selection state machines, the keymap, capture progress formatting) lives in src/state.rs and src/keymap.rs and is unit-tested on the native target:

cargo test -p cbd-web

Components in src/app.rs stay thin over that logic. The server-side serving and the gRPC-web + auth routing are tested in crabidy-server (src/web.rs, tests/web_server.rs).