| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
setup-origin.sh did everything except the step that makes a name usable. It
generated the key, wrote nginx, verified the certificate -- then printed a
base64 string and told a human to go paste it in a browser. Until they did,
every client refused the name, so the automated part produced nothing that
worked on its own.
It turns out no browser is needed. The registry's own router accepts a
bearer token alongside a cookie session:
moshpitRouter.use("/api/moshpit", async (req, _res, next) => {
if (!req.user) {
const user = await userForApiKey(bearer(req));
...
So with MOSHPIT_API_KEY set, the script now publishes the pin and optionally
sets the name's target, and "serve this name" is genuinely one command.
Without a key nothing changes -- it prints the pin exactly as before.
It reads the pin back afterwards rather than trusting the 201. A write being
accepted and the endpoint clients query actually serving it are different
claims, and a pin that is accepted but not served leaves the name refused
with nothing to show for it.
--target refuses an IPv4 literal up front, because the registry refuses one
by design (an A record on a small host is leased, NATed or shared, so a name
pointed at one goes stale silently). The error names the fix -- use a
hostname -- which the API's own message does not.
Also fixes --help, which was consumed as the name and answered
"'--help' does not look like a Moshpit name". Pre-existing.
Request shapes verified against a mock registry, and they match the deployed
routes' setNameTarget({tld,label,target}) and addPin({tld,label,pin,kind}).
sh -n clean; guards for missing --api-key, IPv4 literals and URLs exercised.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
setup-origin.sh did everything except the step that makes a name usable. It generated the key, wrote the nginx block, verified the certificate — then printed a base64 string and told a human to go paste it in a browser. Until they did, every client refused the name, so the automated part produced nothing that worked on its own.
No browser is needed
The registry's own router already accepts a bearer token alongside a cookie session:
So with a key, serving a name becomes genuinely one command:
Key → certificate → nginx → reload → verify → publish the pin → set the target → read it back. Without a key nothing changes: it prints the pin exactly as before.
It reads the pin back
A 201 and "the endpoint clients query actually serves this" are different claims. A pin accepted but not served leaves the name refused with nothing to show for it, so the script confirms rather than assumes:
--target refuses IPv4 up front
The registry rejects IPv4 literals by design — the rationale is in moshpit-gateway.mjs:
The script catches it before the certificate exists, and names the fix (use a hostname) — which the API's own error does not. A hostname is also how a name reaches IPv4-only clients, since the address behind it resolves normally.
Also fixes --help
It was consumed as the name and answered '--help' does not look like a Moshpit name. Pre-existing, not from this change.
Verification
Request shapes checked against a mock registry:
PUT /api/moshpit/tlds/hacker/names Bearer … {"label":"chovy","target":"dev.profullstack.com"} POST /api/moshpit/tlds/hacker/pins Bearer … {"label":"chovy","pin":"v6k99…","kind":"tls","note":"setup-origin.sh"} GET /api/moshpit/tlds/hacker/pins?label=chovyThese match the deployed routes' setNameTarget({tld, label, target}) and addPin({tld, label, pin, kind, note}). sh -n clean; the guards for missing --api-key, IPv4 literals and URLs are all exercised.
Not run end to end against the live registry — that needs a real API key, which I don't have. The HTTP layer is verified against a mock; the first real run is still the first real run.
🤖 Generated with Claude Code