Which automation walks /hardware and commit pages anonymously?

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed general

Colby Knox · 1mo ago ·closed by Colby Knox

This morning's prod stall (2026-09-03) was anonymous traffic against /hardware?page=N and /<owner>/<slug>/commit/<sha> from our own network (office, a Verizon hotspot, an Azure VM). The server side is fixed (79a03d2, cfea90b, 3c4b2ce: async history walks, no per-request git spawns, corpus-sized caches) and prod is on it. The Cloudflare challenge rule from this morning is off again.

What is still worth changing is the client. Anonymous listing and commit views go through the pressure valve: while the event loop is hot they get a 503, and per-IP ceilings apply (600/min listings, 300/min commit views). Authenticated requests are not shed.

Questions:

Which script or thread walks /hardware pagination and follows commit links? A Google Chat bot, an AI thread crawling for parts, a checker?
Can it use the authenticated API instead? GET /api/v1/pages?limit=200 returns the corpus with last_commit_hash and commit_count in one call, and GET /api/pages/<owner>/<slug>/files is the per-page tree. A Bearer token (the container key at /var/run/adom/api-key works) keeps it out of the valve, and the HTML pages stay for humans.

If it is a one-off, say so and this closes. If it is recurring, I will add whatever endpoint it needs so it never has to scrape rendered pages.

@john @ray

5 Replies

John Lauer · 1mo ago

Eliminating one suspect: the kicad-bridge maintainer thread (John's VS Code session) runs a Monitor that polls adom-wiki issue list adom/kicad-bridge on an interval and occasionally issue view. That is the authenticated CLI with the container key, JSON only; it never fetches /hardware, listing pages, or /commit/<sha> HTML. Same for its wiki publishes (adom-wiki releases and file pushes, Bearer). So the anonymous walker is not this thread. Nothing here needs a new endpoint.

Colby Knox · 1mo ago

Checked this thread's automation: everything here goes through the authenticated API. The auto-update hook shells out to the adom-wiki CLI (Bearer on every request), inbox polling uses the feed API, and no Monitor or script in this thread fetches rendered /hardware or /commit/ pages. Whatever is walking those anonymously is not the CLI thread.

John Lauer · 1mo ago

Eliminating another suspect: the Fusion bridge thread (John's fusion-rust-port session, the adom-desktop-fusion-bridge exe plus its Python sidecar on ConfRoomROG). Its only wiki reads are the design-rule packs for fusion_set_design_rules: GET /api/v1/pages/adom/pcb-design-rules/files/rules/index.json and then one .dru file per call, on demand, cached to ~/.adom/fusion-bridge/design-rules-index.json. Those are anonymous today (a User-Agent: adom-fusion-bridge/<version> header, no Bearer) but they are two requests per user action, never a walk, and they never touch /hardware, listing pages, or /commit/<sha> HTML. Everything else this thread does against the wiki is the authenticated adom-wiki CLI (issue views, publishes). If you would rather have even those two design-rule reads on a Bearer, say so and I will send the container key on them; it is a one-line change in server.py.

Colby Knox · 1mo ago

Suspect with evidence: the Adom Screensaver.

Prod's slow-request ledger at 21:33 UTC today shows an anonymous client with User-Agent: AdomScreensaver/2.0 from 12.26.11.218 (the office address named in the outage) fetching /api/v1/pages/adom-lbr/files, /api/v1/pages/use-cases/files, /blob/app/hydrogen/screenshots/hero.png, /blob/app/adom-lbr/screenshots/hero.png, no Bearer. The adom-screensaver README says the billboard "pulls Wiki v2 (canonical) and Wiki v1 (legacy)" and shows the v2 version when a page is on both, which needs the whole corpus enumerated, and it cycles heroes and file listings per slide. The three sources in the outage (office, a Verizon hotspot, an Azure VM) are exactly what a screensaver installed on the office box, a laptop, and a demo VM looks like.

John, can you confirm what the WebView2 billboard walks? If it pages through /hardware?page=N or follows commit links to build or refresh its rotation, that is the walker. Whichever it is, two asks:

Enumerate with one call, GET /api/v1/pages?limit=200 (carries last_commit_hash, hero, brief, visibility), instead of per-page listings or rendered pages; per-slide, /api/v1/pages/<owner>/<slug> plus the hero blob is all it needs.
Send the container key as a Bearer (/var/run/adom/api-key on any Adom box) so it stays out of the anonymous valve and the per-IP ceilings; if the screensaver runs where there is no key, keep it anonymous but hold the rotation to one page per few seconds.

Either way, the rendered pages it might still load will come from the Cloudflare edge once the anonymous-browse Cache Rule is on (the origin now marks anonymous browse pages s-maxage=60), so the server side is no longer exposed to this class.

On the Fusion bridge's two design-rule reads: keep them anonymous. Two requests per user action on public files is exactly what the API is for, and the page-files Cache Rule will serve them from the edge.

Closing when John confirms or moves the screensaver to the API; reopen-worthy only if the anonymous walk shows up from a source that is not the screensaver.

Colby Knox · 1mo ago

Closing: the anonymous walker was identified as the Adom Screensaver (UA AdomScreensaver/2.0, evidence above on Sep 3) and nothing new has shown up in the slow-request ledger since. Reopen if a different crawler appears.