sirius-press/docs/testing.md
Silent Mode 17c60b9e11 fix(sirius-press): the exporter could never reach its own site in Docker
Deployed to a real VPS for the first time. The stack came up, the patched
wizard served, the plugins activated and the 40-check auth suite passed over
the public internet — and then every single export failed:

  cURL error 28: Failed to connect to <public ip> port 8081 after 10001 ms

Not a bug in the export. A container cannot reach the host's own published
port on most Docker hosts; there is simply no route back in. The exporter
renders each page by asking the site for it over HTTP, so the one thing it
depends on is the one thing a container cannot do. This would have hit every
user of the documented install path on their first publish, and the error
says nothing about the cause.

SIRIUS_PRESS_LOOPBACK_URL gives the exporter a second address — in the
bundled stack, the nginx service on the compose network — while the request
still carries the site's real Host header. That matters twice: WordPress
renders exactly the page a visitor gets rather than redirecting to a
canonical URL the container cannot follow, and the internal hostname never
appears in the exported HTML. Verified on the VPS: the page builds, the
content is right, no absolute self-links, no `//web/` leaking out.

Also documents the question underneath it — what WP_HOME should be when the
site's public address is a BCNR name. Not the name: whatever the server is
actually reachable at. The exported links are document-relative, so they work
under the name regardless.
2026-09-22 22:43:30 +02:00

183 lines
6.8 KiB
Markdown

# Testing
Four suites, in rough order of how fast they run and how much they prove.
```bash
tests/run.sh # unit + interop, ~1 second, no services
node tests/live.mjs # end to end against a running instance
```
---
## The fast suites
```bash
tests/run.sh
```
Needs PHP 7.4+ with GMP or BCMath, and Node 18+. About a second, no database
and no server.
| Suite | Checks | What it pins |
|---|---|---|
| `test-crypto.php` | 23 | secp256k1 against published vectors, RFC 6979 determinism, low-S, recovery round trips |
| `test-identity.php` | 44 | CashAddress encode/decode/normalise, BIP-39/32 derivation, both signing envelopes, canonical JSON |
| `test-export.php` | 49 | URL-to-path mapping, document-relative rewriting, gateway path rules |
| `interop.mjs` | 22 | the browser wallet against the PHP one, byte for byte |
**`interop.mjs` is the one that matters most.** Sirius Press implements the
same cryptography twice — PHP verifies, JavaScript signs — and every vector in
that file came from libauth, the library the Sirius portal wallet and the BNS
gateway both use. If the two implementations disagree by a byte, nobody can
log in, and the error looks like a rejected password rather than a hash
mismatch. This suite makes that a test failure instead of a bad evening.
---
## A throwaway instance
You do not need Docker, MySQL or a VPS to run a real Sirius Press. PHP's
built-in server plus the official SQLite drop-in is enough, and it starts in
seconds.
```bash
# 1. a complete tree (copied out of the vendored wordpress/, plugins added)
tools/build.sh
cp -R dist/sirius-press /tmp/wpsite
# 2. SQLite instead of MySQL
curl -fsSL -o /tmp/sqlite.zip \
https://downloads.wordpress.org/plugin/sqlite-database-integration.zip
unzip -q /tmp/sqlite.zip -d /tmp/wpsite/wp-content/plugins/
cp /tmp/wpsite/wp-content/plugins/sqlite-database-integration/db.copy \
/tmp/wpsite/wp-content/db.php
mkdir -p /tmp/wpsite/wp-content/database
# 3. a config (any salts will do for a throwaway)
cp /tmp/wpsite/wp-config-sample.php /tmp/wpsite/wp-config.php
# edit it: DB_* values are ignored by the SQLite drop-in, but add
# define( 'WP_HOME', 'http://127.0.0.1:8760' );
# define( 'WP_SITEURL', 'http://127.0.0.1:8760' );
# 4. run it
php -S 127.0.0.1:8760 -t /tmp/wpsite
```
Then open `http://127.0.0.1:8760/wp-admin/install.php`. The setup screen asks
for a wallet address instead of an email one — that alone confirms the core
patch applied.
PHP needs `pdo_sqlite`, `sqlite3`, `gd`, `mbstring` and one of GMP or BCMath.
**Set pretty permalinks before testing publishing.** With plain permalinks
every post's URL is `/?p=N`, whose path is `/`, so the whole site maps to
`index.html` and each page overwrites the last. The Publishing screen refuses
to let this pass quietly, but a script driving the queue directly will not see
the warning.
---
## End to end
```bash
WALLET=/tmp/admin-wallet.json BASE=http://127.0.0.1:8760 node tests/live.mjs
```
`WALLET` is a JSON file holding an administrator's phrase and address:
```json
{ "phrase": "twelve words …", "address": "bchtest:qq…" }
```
40 checks covering sign-in, replay refusal, a stranger's signature, a
signature over altered text, purpose separation, registration, the recovery
page and the REST endpoints — against a real WordPress, with real sessions.
It creates one account per run, so point it at a throwaway.
### Running it with the ecosystem loaded
The suite is worth far more with third-party plugins active, because it then
also proves the fork's admin screens survive them:
```bash
for p in wordpress-seo contact-form-7 woocommerce; do
curl -fsSL -o "/tmp/$p.zip" "https://downloads.wordpress.org/plugin/$p.zip"
unzip -q -o "/tmp/$p.zip" -d /tmp/wpsite/wp-content/plugins/
done
# activate them, then re-run tests/live.mjs
```
If you hit a 429, the rate limiter is doing its job — it caps signature
verification per client. Clear it between runs:
```sql
DELETE FROM wp_options WHERE option_name LIKE '%_transient_%sirius_rl_%';
```
---
## Publishing, without a registered name
The upload path cannot be tested end to end without a BCNR name and the key
that owns it. What *can* be tested is the part that actually breaks — the
bytes being signed — against the real verifier:
```bash
node tests/mock-gateway.mjs --owner bchtest:qq… --port 8799
```
This implements `PUT /api/site/<name>/<path>` with the signature check
transcribed from `Argus/src/gateway/public-gateway.mjs`: same envelope, same
digest, same recovery, same comparison against the owner. A request it accepts
is one the real gateway accepts.
Point the site at it — **Sirius Press → Settings**, gateway
`http://127.0.0.1:8799` — store the matching phrase, publish a post, and watch
the queue drain. Signing with any other key gets the same 403 the real gateway
returns.
It needs `@bitauth/libauth` resolvable from the script, which is the point: it
verifies with the same library the gateway does, not with ours.
---
## In a browser
Everything above drives the site over HTTP, which is fast and repeatable and
misses a whole class of bug. Two got through it and were only found by opening
`wp-login.php` in a browser and clicking the button:
- WordPress marks its username and password inputs `required`. The wallet path
leaves both empty on purpose, so `requestSubmit()` failed constraint
validation and refused to send a perfectly good signature — with a bubble
pointing at a field the visitor is not meant to fill in.
- The `hidden` attribute does not survive WordPress's own stylesheet.
`.wp-core-ui .button { display: inline-block }` outranks the UA rule that
makes `hidden` work, so buttons this plugin ships hidden were on screen
anyway, inverting the progressive-enhancement design.
So: **after changing anything in `plugins/sirius-press-auth/assets/`, open the
login page and click the button.** The HTTP suites will not tell you.
Serve the throwaway instance and point a browser at
`http://127.0.0.1:8760/wp-login.php`. `127.0.0.1` counts as a secure context,
so WebCrypto works over plain HTTP there — on any other host the in-page
wallet needs real HTTPS, and the script says so and falls back to the paste
box.
Worth checking by hand, in this order: the sign-in button appears, the
browser-wallet button does *not* (unless you are in Theseus), typing the
phrase and clicking signs and lands you on the dashboard, and the challenge
text in the box matches what your wallet shows you.
---
## What is not covered
- **A real gateway upload.** The signing is verified against the transcribed
verifier above, and against the real gateway's answer about who owns a name,
but no byte has yet been written to `navigate.st` under a registered name.
- **Manual-mode publishing in a browser.** The server-signing path is
exercised end to end; the browser-signs-and-uploads path in
`assets/export.js` has not been clicked through.