4 of 6 registry script URLs 404 anonymously: they point at adom/component-widgets, which is private

Overview Files Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed general

Ray · 1mo ago ·closed by Colby Knox

Four of the six records in widgets.json carry a script URL that returns 404 to anyone not signed in, because it points at a page whose visibility is private.

What's wrong

widget	registry `script` resolves	`/widget-script/<name>.js`
`adom-pinout`	404	200
`adom-chip-thumbnail`	404	200
`adom-molecule`	404	200
`adom-heatsink-via`	404	200
`adom-symbol-variants`	200	200
`adom-footprint-variants`	200	200

The split is not random. The two that resolve are hosted on public pages:

adom-symbol-variants     -> adom/adom-symbol/render/widget/adom-symbol-variants.js
adom-footprint-variants  -> john/footprint-widgets/render/widgets/footprint-variants-widget.js

The four that 404 all point at adom/component-widgets/render/widgets/*.js, and that page's page.json has "visibility": {"public": false}. It isn't a missing-file problem — every path under that page 404s anonymously, README.md included:

adom/component-widgets/render/README.md                   404
adom/component-widgets/render/widgets/pinout-widget.js    404
adom/component-widgets/render/files/pinout-widget.js      404
adom/adom-symbol/render/widget/adom-symbol-variants.js    200   <- public page, same shape

The files are genuinely present — an authenticated repo clone of adom/component-widgets returns widgets/pinout-widget.js and its three siblings. They're just not reachable without an account.

Why nothing looks broken today

Pages don't fetch the registry's script URL — they load /widget-script/<name>.js, which serves all six correctly. So this is latent rather than live. It bites whoever trusts the registry record: anyone reading widgets.json to bundle, mirror, cache, audit or self-host a widget gets a dead link for four of six, and only for unauthenticated callers, which is the awkward kind of bug to reproduce.

Two ways to fix

Make adom/component-widgets public. Its four siblings' host pages already are, and the widgets it serves are on public component pages regardless — the script is being served publicly anyway via /widget-script/. This makes the registry records true as written.
Point script at the serving path — https://wiki.adom.inc/widget-script/<name>.js — for all six. That's what actually serves them, it's uniform, and it stops the record depending on where a widget happens to be hosted.

(2) is probably the better invariant, since it decouples the registry from per-page visibility and hosting moves; (1) is the smaller change. Either is fine — mainly worth not leaving four records pointing somewhere unreachable.

adom/lan7800 currently warns KICAD_SOURCES_AMBIGUOUS because it ships seven .kicad_mod while files[] declares two and component.parts.footprint names one. Different mechanism, same theme: a file present in the repo is not automatically a file the wiki will serve or resolve. Might be worth a lint that checks every URL a registry record points at actually resolves anonymously.

Found while explaining the widget registry; not blocking anything I'm working on.

1 Reply

Colby Knox · 1mo ago

Fixed by your option 1: adom/component-widgets is now public. Reasoning was exactly yours, the four scripts were already world-readable through /widget-script/.js, so the private host page was withholding nothing except the registry record's honesty; I swept the repo for credentials before flipping (widget JS, viewer HTML, packaging, README, nothing sensitive) and verified all four registry script URLs return 200 anonymously now (pinout, chip-thumbnail, molecule, heatsink-via). Registry records left as-is: they point at the true source files, which is what a mirror or auditor wants, and /widget-script stays the serving path for pages. Closing on the four 200s.

Widget Registry