aboutsummaryrefslogtreecommitdiffstats
path: root/packaging/build
diff options
context:
space:
mode:
authorChristophe Besson <cbesson@gmail.com>2026-09-02 10:35:17 +0200
committerChristophe Besson <cbesson@gmail.com>2026-09-02 10:35:17 +0200
commit9c1b622611bb0b21852d3c9c11e1d8674aa35654 (patch)
tree68261f4451047a58c0554f0ceeddaf65214f7131 /packaging/build
parente08bb408cf9963066f212028e69e22c46ff1cb54 (diff)
downloadmeshbay-9c1b622611bb0b21852d3c9c11e1d8674aa35654.tar.gz
fix(hub): check the captcha's origin here, so the desktop client can pass one
Reported from the native client: the reCAPTCHA box renders "ERROR for site owner: Invalid domain for site key". The web browser is fine. It is not a client restriction, and the CSP was never what refused — the script loads, which is why the widget appears at all to say so. reCAPTCHA validates the hostname of the page the widget is rendered in against the domain list on the site key, and the desktop client's interface ships inside the package and is served from `app://meshbay` (main.js: `win.loadURL`). Not a preference: file:// breaks ES modules and IndexedDB, and the hub must never become the document origin. So the hostname Google sees is `meshbay`, it is not on the key's list, and it never can be — the check runs on Google's servers and nothing client-side reaches it. The fix turns that check off on the key and does it on the hub instead: [captcha] allowed_hosts = ["meshbay.org", "localhost", "meshbay"] `verify_captcha` refuses a solve whose hostname is not in the list. The hostname comes from `siteverify` — what Google observed, not what the caller asserts — so it is a real check against what turning the console setting off opens, which is a bot rendering the public site key on a page of its own. Empty (the default) skips it, so an existing hub upgrades unchanged with reCAPTCHA still doing the origin check. The two settings go together, and docs/captcha.md §6 says so. The `meshbay` entry is the weak one and the doc says that too: any Electron application can claim the same scheme and host, as main.js already records. What it still costs is a captcha solve per token inside a real Chromium instead of a token farmed from any web page. docs/captcha.md §6 replaced. It documented a design that was superseded twice — an `auth_key`-keyed carve-out that turned out to disable the gate for everyone, and "works in the Electron client too, both run Chromium", which is the assumption this bug is made of: reCAPTCHA validates the domain, not the rendering engine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014UtzVrzM7e2tG9fSpkR9ML
Diffstat (limited to 'packaging/build')
0 files changed, 0 insertions, 0 deletions