a6f7b335a5
The PIN could only be six digits and was set from three bare inputs; the unlock prompt sat at the top of the page; and the password manager only filled when you found the key chip, never offered to save, and "Clear cookies on quit" signed you out of every site, including the ones whose login the vault already holds. - PINs are 6 to 8 digits. The PIN record stores its length so pads draw the right number of dots and submit on the last digit; a PIN of the wrong length is refused without a strike, so an older Aegis pad cannot burn the count against an 8-digit PIN. - Settings sets a PIN in steps: master password, choose the PIN on a pad (6/7/8), repeat it, done. The locked vault opens Theseus's own prompt, which is now centred, with the PIN pad or the master password field. - After a sign-in or sign-up form is sent and the page moves on, Theseus offers to save (or update) the login, with an optional "ask for my PIN or password before filling it". Focusing a login form offers the saved logins under it; on a locked vault it offers to unlock first. A failed login (the password field still showing) gets no offer. - "Keep sign-ins for sites in your vault" (on): the quit clear spares the cookies and site storage of sites with a saved login. Their hostnames are kept sealed with the OS keystore so the list is readable at quit while the vault is locked. Verified end to end on a scratch profile: signed in, restarted, still signed in; another site's cookie was cleared. |
||
|---|---|---|
| .. | ||
| bcnr-selftest.js | ||
| blocklist-selftest.js | ||
| list-tlds.mjs | ||
| origin-selftest.mjs | ||
| probe-site.mjs | ||
| README.md | ||
| registry-decide.mjs | ||
| rescheck.mjs | ||
| selftest.js | ||
| show-tlds-bch.mjs | ||
| signin-sites.test.cjs | ||
| test-directip.mjs | ||
| test-our-indexer.mjs | ||
| vault-pin.test.cjs | ||
Theseus dev/test harness
Two ways to drive Theseus's resolution + content path headlessly, for testing
and debugging without clicking through the GUI. Both use the real resolver
(Argus/src/lib/resolver-web.js) and gateway path the shipped app uses.
selftest.js — full render (Electron)
Runs the actual serveBns protocol handler (imported from main.js) in a
hidden offscreen Electron window, loads a bns:// name, lets its JavaScript
execute, then reports what really rendered and writes a screenshot.
npx electron dev/selftest.js hello.bch
npx electron dev/selftest.js coinspectrum.deviant.bch # JS-driven Sia site
THESEUS_SETTLE=8000 npx electron dev/selftest.js <name> # wait longer for data
Output: a JSON report (title, badge, stylesheet/script counts, local vs external
broken-image counts, visible-text length, failed loads, verdict) plus
dev-out/render.png and dev-out/render.html. Exit 0 = PASS. The verdict counts
only the site's own bns:// assets — external CDN images are informational.
This is the faithful version of manual tests #2 (Sia-via-gateway rendering) and
#3 (multi-TLD badge). main.js exports its handler and skips auto-launch when
THESEUS_NO_AUTOSTART=1, which the harness sets.
probe-site.mjs — content path only (Node, no Electron)
Fast check with no display or Electron: resolves a name, fetches the index
through the gateway exactly as serveBns does (with the <base> strip), and
fetches each static same-origin asset, reporting status/content-type.
node dev/probe-site.mjs coinspectrum.deviant.bch
Limitation: static-HTML only. It cannot see assets a page builds at runtime in
JavaScript — use selftest.js for JS-driven sites.
dev-out/
Generated render artifacts (screenshot + HTML dump). Safe to delete; regenerated
on each selftest.js run.