Commit Graph
5 Commits
Author SHA1 Message Date
kevinveenbirkenbachandClaude Opus 5 39d8de790b test(web-app-wordpress): cover the OIDC payload instead of exempting it
Two lint suppressions shipped with the multisite OIDC work. Both are replaced
by the thing they were standing in for.

settings.php claimed an exemption from the mirrored-test rule because every
call it makes belongs to the WordPress runtime. The six functions stub in a
few lines, so the claim does not hold. SettingsTest.php declares WP_CLI and
the globals over a state holder and includes the real payload per case:

  * a single site is written without switching blogs
  * every site of a network is written, switch_to_blog paired with restore
  * a site whose write does not persist is named by blog id
  * every site is still visited before that failure is reported
  * a payload that is not a map halts, and so does an absent one

The fourth case is the one worth having: a `break` on the first failure would
pass the other three and silently stop writing.

Neither existing house pattern fits. `eval` suits the tag-less tinker snippet
of web-app-akaunting, `proc_open` the standalone script of web-app-joomla;
this is a tagged file that needs a runtime, so it is stubs plus `include`,
which also avoids the `nocheck: eval` the akaunting test carries.

The installer test's cache-read exemption rested on a cached read serving a
stale call log. Measured, that risk is confined to the suite and sits around
3e-13: the log lives in a fresh TemporaryDirectory per run, mkdtemp verifies
non-existence, and each path is read once. What complying actually costs is
roughly 25 dead entries in an 8192-slot LRU, so the read goes through
utils.cache.files.read_text.

Proven by `make test-unit-php`: 32 tests, 68 assertions. The first version of
this test passed nothing at all -- it sits one directory deeper than the
other PHP tests, so dirname(__DIR__, 6) resolved to tests/ and the include
found no file. Without the test that would have stayed invisible.

The suite drives stubs, so it proves the payload's control flow and not that
WordPress behaves as stubbed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-10-06 22:54:27 +02:00
kevinveenbirkenbachandClaude Opus 5 4ba57c1fce fix(web-app-wordpress): activate plugins across a multisite network
A Multisite subsite served `/wp-login.php` with no SSO entry point even once
the OIDC settings reached every site (e1901fb88e), because the plugin was
never running there:

    wp plugin activate <name> --path=<docroot>

Without `--network` that activates the main site only, so a subsite had the
settings and no plugin. `--network` appears on no branch of this repository,
so the gap was everywhere.

`services.wordpress.multisite.enabled` now resolves once, in vars/main.yml,
and feeds the activation, the multisite conversion gate and playwright.env.j2,
which until now recomputed the same lookup inline. The conversion gate also
drops a `| default(false)` on a key meta/services.yml always declares.

The installer moves out of Ansible into files/shell/install_plugin.sh. Eight
tasks interlocking through register/when/until/failed_when read as one linear
script, and the contract arrives as environment assignments. The container
address stays an inline shell assignment rather than an `environment:` entry
because in swarm it is the literal text `"$(resolve-container-id ...)"`, which
only the shell evaluates; the body streams over stdin because swarm workers
carry no role checkout (03ed52eea5).

Moving the logic across languages would have dropped the WP-CLI 255 contract
to shellcheck coverage, since the suite has no shell tests. The unit suite
therefore now drives the real script against a stubbed `container` wrapper
instead of evaluating the task file's `when:` expressions, which exercises the
behaviour rather than the text describing it.

A mutation pass over that suite -- eight mutations, each required to turn its
own guard red -- found two defects before any deploy:

  * `set -e` is suspended inside an `if` condition, so a probe folded into
    `if needs_install; then` turned an unreadable version into "nothing to
    do". The version read is now a standalone call that aborts with 67.
  * a bare `return` propagates the status of the preceding test, so
    `[ -n "$WP_PINNED_VERSION" ] || return` aborted the script whenever an
    unpinned plugin was already present -- the path every redeploy takes.

The second hid behind a vacuously passing check, which is why the suite gained
exit-code assertions where it previously only counted calls.

This commit carries a fix and a refactor together. The `--network` fix lives
inside the extracted script's activate(), so separating them would mean
reverting the extraction, committing the flag, and reapplying it.

No deploy has run any of this, in compose or in swarm.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-10-06 21:00:44 +02:00
kevinveenbirkenbachandClaude Opus 5.5 52fe3c9c2c style: apply make autoformat to the merged Stalwart and Tor files
Formatter output only: the parsed YAML and the Python AST of every touched file equal their previous versions.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-03 19:57:30 +02:00
Alejandro Roman a390fea9e9 fix(swarm-stalwart): fix CI issues, cmments mapache 2026-09-28 18:23:16 +04:00
kevinveenbirkenbachandClaude Opus 5 604843bb87 fix(wordpress): refuse an MCP request the site cannot attribute to a user
The mu-plugin header describes the split as 'the adapter authorises the transport, the callback authorises the operation'. The second half held, every ability carries infinito_mcp_may_read. The first did not: the adapter answered the initialize handshake to anyone, so the server and its protocol version were readable without a credential.

Measured in run 34653754175, the swarm WordPress#0: test-mcp-guest.js posts an anonymous initialize and expects at least 400, and the error context reads 'Expected: >= 400, Received: 200'. Its neighbour addons/mcp-adapter.spec.js posts an anonymous tools/list and passed, so the tool call was already refused and only the handshake was not.

The filter hangs on rest_pre_dispatch and refuses every route under the mcp namespace while the site cannot attribute the request. It leaves an already short-circuited response alone rather than overwriting it, scopes itself by route prefix so the rest of the REST API stays as open as it was, and reaches is_user_logged_in, which triggers determine_current_user and with it wp_validate_application_password, so a client presenting its application password passes. A WP_Error renders no jsonrpc key, which is the second thing the spec asserts.

The new unit test reads the guarded prefix out of the PHP and the endpoint out of the spec and requires the endpoint to sit under the prefix. Without it an adapter that moves namespace would leave the guard protecting nothing while both negative specs keep passing.

A positive spec was tried and reverted: handing the MCP credential to the Playwright env is forbidden by tests/lint/ansible/services/test_mcp_secret_not_in_playwright.py, because the trace travels in the CI artifact. No role probes its MCP endpoint with the credential at deploy time either, so the authenticated direction stays unproven.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-12 09:54:28 +02:00