Extension lane never answers HTTP Basic-Auth from the vault (st.componentsearchengine.com CAD download stalls on Chrome's Sign in dialog)

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed bug report

John Lauer · 1mo ago ·closed by John Lauer

Summary

pup does not answer Chrome's native HTTP Basic-Auth dialog from the vault on the extension lane. Navigating to a CSE download URL leaves the "Sign in — https://st.componentsearchengine.com" dialog open in the pup window, the frame reports "error page", pup_eval / pup_fetch_url hang or fail, and no file is downloaded — even though credential_list on this box holds componentsearchengine.com and ms.componentsearchengine.com (two usernames each). The chip-fetcher playbook (credentials-and-logins.md) documents the opposite: "pup calls page.authenticate() with the matching vault entry before every navigate, so Chrome's auth dialog never appears." That holds only on the CDP lane; the default extension lane has no CDP session, so it cannot call page.authenticate(), and nothing else supplies the credential.

Form logins are fine on the same box: pup_login on app.ultralibrarian.com (vault:app.ultralibrarian.com) signed in and the page reads "Hello [email protected]"; pup_login on my.st.com filled + submitted from vault:my.st.com (ST rejected the stored password, a stale credential, not a pup fault).

Environment

Windows (AdomLapper), Adom Bridge 2.1.130, pup (puppeteer bridge) 2.0.641, extension lane, shared adom-you profile
Vault: credential_list shows 871 entries incl. componentsearchengine.com, ms.componentsearchengine.com, nxp.componentsearchengine.com

Repro

pup_open_window {sessionId:"cse-fetch", url:"https://st.componentsearchengine.com/entry_u_newDesign.php?mna=STMicroelectronics&mpn=VL53L5CX&pna=st&vrq=multi&fmt=zip&logo=&lang=en&epm=2"} → ok, title "SamacSys Part Preview" (the ST CAD Resources widget: symbol, footprint, 3D, "Download CAD Models").
pup_eval click #mvDownloadButton → tab navigates to https://st.componentsearchengine.com/ga/model.php?fmt3d=stp&partID=15569520&partner=STMicroelectronics&tok=0&emb=1&lang=en-GB&pna=STMicroelectronics.
desktop_screenshot_window of the pup window: Chrome's native "Sign in / https://st.componentsearchengine.com / Username / Password" dialog is open on a blank page.
pup_eval {sessionId:"cse-fetch", ...} → Frame with ID 0 is showing error page.
pup_fetch_url {sessionId:"cse-fetch", url:<the model.php URL>} → fetch_failed: Runtime.evaluate failed: 0 cdp did not settle within 40000 ms (a Chrome API hung).
No .zip/.stp appears under %USERPROFILE%\Downloads, %LOCALAPPDATA%\Adom Bridge, %TEMP% or C:\Users\john\.adom\** in the following 60 minutes.

Expected

The vault entry for the registrable domain (componentsearchengine.com, any subdomain, i.e. *.componentsearchengine.com) answers the 401 challenge silently on every lane; the zip downloads (or pup_fetch_url returns it as bodyBase64); the AI never sees the dialog.

Proposal

Extension lane: supply Basic-Auth credentials with chrome.webRequest.onAuthRequired (blocking, authCredentials) from the vault, matched on the registrable domain so st./ms./nxp.componentsearchengine.com all match a componentsearchengine.com entry. CDP lane: keep page.authenticate().
When no entry matches, do not leave the native dialog up: return errorCode: no_credential with the challenging host, and a _hint that names the three routes in order — pup_import_browser_logins {} (the user's own Chrome/Edge saved logins, one consent + one UAC, fine for first-time discovery), pup_vault_sync {peer} (with a hostFilter, so a shared/conference-room box does not receive the user's whole vault), then credential_set {host:"*.<domain>"}.
When the human types into the native auth dialog in the pup window, capture that credential into the vault on success, the way form logins are captured on submit.
pup_fetch_url on a tab whose frame is an error page should fail fast with a typed error instead of a 40 s CDP hang.

Found while

Fetching ST's real STEP models for VL53L5CX / VL53L7CX / VL53L8CX for the Adom release-video run of "make me a KiCad/Altium/Fusion library for the three cheapest 8x8 ToF sensors": ST's CAD Resources tab is a SamacSys widget whose download is Basic-Auth on st.componentsearchengine.com. The site skill (john/electronics-sites-skillpack skills/st) and chip-fetcher-sites/sites/st both assume this just works.

2 Replies

John Lauer · 1mo ago

Fixed in pup 2.0.644, on insiders as 2.0.645 (installed on AdomLapper).

What ships

The extension lane now answers HTTP Basic/Digest challenges from the vault: the worker's chrome.webRequest.onAuthRequired (asyncBlocking, webRequestAuthProvider) asks pup over a new /extauth endpoint, and pup matches on the registrable domain, so st. / ms. / nxp.componentsearchengine.com all resolve a componentsearchengine.com entry.
With no entry, pup cancels the challenge so the native dialog never blocks the window, and the next pup_navigate / pup_fetch_url returns errorCode: no_credential naming the host, with the three routes in order: pup_import_browser_logins, pup_vault_sync {peer, hostFilter}, credential_set {host:"<domain>"}.
A stored credential the server rejects is tried once, then reported the same way (keyed per request id, so a rejection is never confused with a fresh challenge).
pup_fetch_url runs on the extension lane now (it was going to a CDP session this lane never had, hence the 40 s hang).

Measured on ConfRoomROG against httpbin's basic-auth endpoint: with a vault entry the page reads "authenticated": true and pup_fetch_url returns; after credential_delete, navigate and fetch both return no_credential immediately, no dialog. Foreground gate, parity and smoke at baseline.

Not done: capturing a credential the human types into the native dialog (ask 3). With the challenge cancelled the dialog never appears, and the extension API exposes no way to read it if it did. The no_credential hint covers first-time discovery through the browser-login import instead.

Recipe note added to the pup-credentials skill.

John Lauer closed this · 1mo ago

John Lauer · 1mo ago

Confirmed the auth half on AdomLapper (pup 2.0.645): pup_fetch_url against https://st.componentsearchengine.com/ga/model.php?fmt3d=stp&partID=15569520&... now answers status:200, contentType:"application/x-zip", ok:true with no native dialog — the vault entry for componentsearchengine.com resolved st. as designed. Thank you.

One regression in the same path, measured 2026-09-19 ~14:40Z, ext lane, session cse3:

The body comes back in text (the zip decoded as UTF-8, length: 1814794), not bodyBase64 — the pitfalls line in the same reply still says "returns base64 — decode it caller-side". Binary bytes ≥ 0x80 are mangled, so the zip cannot be reconstructed caller-side (zipfile.BadZipFile).
saveTo (container-side) fails in the CLI with pup_fetch_url: bridge didn't return bodyBase64 — cannot fulfill container-side saveTo (and the CLI then prints the whole mangled body, 2.5 MB, into the tool result).
desktopSaveTo: "C:/Users/john/Downloads/VL53L5CX_cse.zip" is ignored: reply has no savedTo/desktopSavedTo, nothing written.

Ask: on the ext lane, return binary content types as bodyBase64 (or always base64, as the hint promises), honour saveTo / desktopSaveTo (Mode A/B from the chip-fetcher adom-bridge-api playbook), and never echo a binary body as text. Text content types can keep text.