From 2d8c6bc449e343a80569e45d4ceae0423616cedd Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Wed, 2 Sep 2026 11:54:22 +0200 Subject: fix(hub): a desktop solve reports no hostname at all, not "meshbay" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Registering from the native client failed with `captcha_failed` while the checkbox was green — a worse symptom than the one being fixed, because the widget now looked fine and only the hub's own log said otherwise: captcha solved on an unexpected host ''; allowed: ['localhost', 'meshbay', 'meshbay.org'] The previous commit assumed Google would report the host component of the origin, so `app://meshbay` would come back as `meshbay` and could sit in `allowed_hosts`. It does not. A solve Google cannot attribute to a domain reports an **empty** hostname, and no allowlist entry can match that. An empty entry is not the answer either: a blank in a TOML list is a typo far more often than an intention, and `load_config` drops blanks for that reason — `captcha.allow_unattributed_host` is a named flag instead, so the trade is stated where it is made. What it admits, plainly: every non-web client, not only ours. A file:// page or somebody else's Electron application look identical from here. That is the same bar the client's own origin would have been — main.js already records that `app://meshbay` is not a credential — and it is a bar: the captcha still has to be solved, per token, in something that can render it. What is given up is the origin restriction for non-web clients, not the captcha. Off by default, and a hub without the desktop client should leave it off. The refusal now names which of the two it is, since they need different answers: an unexpected host names the host, an unattributed one says to set the flag. docs/captcha.md §6 said `meshbay` was the value and told operators to add it; it now records what was measured and why the guess was wrong. The packaged example config carries the flag with the same warning. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML --- packaging/conf/hub.toml.example | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) (limited to 'packaging') diff --git a/packaging/conf/hub.toml.example b/packaging/conf/hub.toml.example index d647707..7f5ac8f 100644 --- a/packaging/conf/hub.toml.example +++ b/packaging/conf/hub.toml.example @@ -66,8 +66,18 @@ secret_key = "" # and is served from `app://meshbay`, so the hostname Google sees is not this # hub's and never can be; with the console check on, the widget shows # "Invalid domain for site key" and nothing client-side reaches that decision. -# Add the client's own host only if you distribute it — it is the weak entry, -# since any Electron application can claim the same scheme and host. # -# allowed_hosts = ["hub.example.org", "localhost", "meshbay"] +# allowed_hosts = ["hub.example.org", "localhost"] allowed_hosts = [] + +# A solve Google cannot attribute to a domain reports an *empty* hostname — +# the desktop client's `app://` origin does, and so does any other non-web +# client. No `allowed_hosts` entry matches that, hence a flag rather than a +# blank list entry. +# +# What it admits is every non-web client, not only this project's: a file:// +# page or somebody else's Electron application look identical from here. The +# captcha still has to be solved per token; what is given up is the origin +# restriction for those clients. Leave it off unless you ship the desktop +# client. See docs/captcha.md §6. +allow_unattributed_host = false -- cgit v1.2.3