fix(wordpress): route the outpost OAuth path so the gate is a gate, not a dead end

Verified against the deployed cluster: GET /wp-admin/ correctly 302s to https://www.renner.uno/outpost.goauthentik.io/start?rd=... — and that URL returned WordPress's 404 page, because /outpost.goauthentik.io fell through to the public '/' prefix router. The effect was that /wp-admin was unreachable rather than protected. An attacker gains nothing, but neither does the editor the gate exists for. paperless needs the same route and solves it with a separate Ingress on auth.renner.uno (apps/authentik/paperless-gate-ingress.yaml). Here the whole flow stays on www.renner.uno, so the path belongs in this rule set. These endpoints are the login flow itself and are served by the outpost, so routing them to it is not an authentication hole. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014giKN9N6e5J2DF8QZmVh98
Merge pull request 'fix(wordpress): remove add_filter from wp-config, route xmlrpc through the gate' (#493 ) from fix-wordpress-config-extra into master
2026-08-16 22:22:25 +02:00 · 2026-08-16 20:13:31 +00:00 · 2026-08-16 22:11:25 +02:00 · 2026-08-16 20:07:03 +00:00
2 changed files with 38 additions and 4 deletions
@@ -64,10 +64,12 @@ spec:
                   would only fail against a read-only docroot. Plugin and
                   theme installs are unaffected. */
                define('WP_AUTO_UPDATE_CORE', false);
-                /* xmlrpc.php is blocked at the ingress; this closes the same
-                   door from the inside. Nothing here uses it: no Jetpack,
-                   no mobile app, no pingbacks worth keeping. */
-                add_filter('xmlrpc_enabled', '__return_false');
+                /* No add_filter() here. WORDPRESS_CONFIG_EXTRA is eval'd inside
+                   wp-config.php, long before wp-settings.php loads the plugin
+                   API, so any add_filter call is a fatal error on every request
+                   — which is exactly what happened on first deploy. xmlrpc is
+                   handled at the ingress instead, by routing /xmlrpc.php
+                   through the Authentik gate. */
          envFrom:
            # The eight WordPress salts. Rotating them in OpenBao invalidates
            # every session — which is the intended lever, not a side effect.
@@ -57,6 +57,24 @@ spec:
    - host: www.renner.uno
      http:
        paths:
+          # The outpost's own OAuth leg. Without this the gate is a dead end,
+          # not a gate: hitting /wp-admin redirects to
+          # /outpost.goauthentik.io/start on THIS host, which otherwise falls
+          # through to the public `/` router and lands on WordPress's 404
+          # page — verified exactly that way on first deploy. paperless needs
+          # the same route and has it as a separate Ingress on auth.renner.uno
+          # (apps/authentik/paperless-gate-ingress.yaml); here the flow stays
+          # on www.renner.uno, so it belongs in this rule set.
+          #
+          # It is not an authentication hole: these endpoints ARE the login
+          # flow, and the outpost serves them itself.
+          - path: /outpost.goauthentik.io
+            pathType: Prefix
+            backend:
+              service:
+                name: ak-outpost-wordpress-gate
+                port:
+                  number: 9000
          # Covers admin-ajax.php too. That is only safe because the gift
          # registry plugin -- the sole thing on this site that ever emitted
          # an ajaxurl -- is being dropped in the migration. Verified against
@@ -76,3 +94,17 @@ spec:
                name: ak-outpost-wordpress-gate
                port:
                  number: 9000
+          # xmlrpc.php would otherwise be served by the public `/` prefix
+          # router — an earlier version of this file claimed it was "blocked
+          # at the ingress" while nothing blocked it at all. There is no deny
+          # verb in an Ingress, so it goes through the gate instead: anonymous
+          # callers get Authentik, not the XML-RPC endpoint. Nothing on this
+          # site uses it (no Jetpack, no mobile app, no pingbacks worth
+          # keeping), so no legitimate caller is affected.
+          - path: /xmlrpc.php
+            pathType: Exact
+            backend:
+              service:
+                name: ak-outpost-wordpress-gate
+                port:
+                  number: 9000
Author	SHA1	Message	Date
claude-botandClaude Opus 5	fb3724f603	fix(wordpress): route the outpost OAuth path so the gate is a gate, not a dead end ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details Verified against the deployed cluster: GET /wp-admin/ correctly 302s to https://www.renner.uno/outpost.goauthentik.io/start?rd=... — and that URL returned WordPress's 404 page, because /outpost.goauthentik.io fell through to the public '/' prefix router. The effect was that /wp-admin was unreachable rather than protected. An attacker gains nothing, but neither does the editor the gate exists for. paperless needs the same route and solves it with a separate Ingress on auth.renner.uno (apps/authentik/paperless-gate-ingress.yaml). Here the whole flow stays on www.renner.uno, so the path belongs in this rule set. These endpoints are the login flow itself and are served by the outpost, so routing them to it is not an authentication hole. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014giKN9N6e5J2DF8QZmVh98	2026-08-16 22:22:25 +02:00
k.renner	8d1c4eb7ca	Merge pull request 'fix(wordpress): remove add_filter from wp-config, route xmlrpc through the gate' (#493 ) from fix-wordpress-config-extra into master ci/woodpecker/cron/alert-monitor Pipeline was successful Details Reviewed-on: k.renner/homelab#493	2026-08-16 20:13:31 +00:00
claude-botandClaude Opus 5	faf79549ac	fix(wordpress): remove add_filter from wp-config, route xmlrpc through the gate ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details The first deploy returned 500 on every request: PHP Fatal error: Uncaught Error: Call to undefined function add_filter() in /var/www/html/wp-config.php(128) : eval()'d code WORDPRESS_CONFIG_EXTRA is eval'd inside wp-config.php, which runs long before wp-settings.php loads the plugin API. add_filter() does not exist yet at that point, so the call was fatal on every request. Removing it exposed the second, worse half: the comment justified the filter by claiming xmlrpc.php was 'blocked at the ingress'. It was not. The public router matches '/' as a prefix, so xmlrpc.php was served like any other path — the claim was written without being checked. An Ingress has no deny verb, so xmlrpc.php now routes to the Authentik gate alongside /wp-admin and /wp-login.php: anonymous callers meet Authentik instead of the XML-RPC endpoint. Nothing on this site uses it — no Jetpack, no mobile app, no pingbacks worth keeping. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014giKN9N6e5J2DF8QZmVh98	2026-08-16 22:11:25 +02:00
k.renner	5336d9b849	Merge pull request 'feat(wordpress): migrate renner.uno off the Hetzner VM into the cluster' (#492 ) from wordpress-renner-uno into master ci/woodpecker/push/deploy-infrastructure Pipeline was successful Details Reviewed-on: k.renner/homelab#492	2026-08-16 20:07:03 +00:00