mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-11 13:17:07 +00:00
kevinveenbirkenbachandClaude Opus 5
adacac7f29
The WordPress MCP endpoint answered 401 to every authenticated call, and
web-app-hermes and web-app-openclaw failed their CLI tests as cascades of the
same refusal. The WordPress container's own Apache log settles it: 121 POST,
100 GET and 21 HEAD on the MCP path, each with %u = mcp-web-app-wordpress and
status 401. A populated %u rules out a stripped Authorization header, and the
body is infinito_mcp_unauthorized, which only the mu-plugin's rest_pre_dispatch
guard emits - a wrong password for an existing user would surface WP core's
incorrect_password instead. So WordPress never resolved a user, because the
deploy sent the users-dict key while the login the deploy creates is
mcp-wordpress.
7916c0177e introduced the split when it capped usernames, deliberately keeping
the key because meta/mcp.yml's owner and the token store wire to it.
web-app-wordpress is the only role with auth: basic_auth - every other MCP
provider uses bearer, where the owner never travels - which is why only this
one broke.
resolve_credential now also returns the login, mcp_servers emits it on every
discovered entry, and the filter encodes login:token. It raises when no login
resolves rather than authenticating as the empty user, so the failure is loud
instead of another 401. The new mcp_client_login lookup shares
resolve_provider_credential with mcp_client_bearer so a second resolver cannot
drift from the first, and a test pins the two to the same function object.
test.env.j2 is the one place that hand-builds the server dict instead of
reading MCP_DISCOVERED_SERVERS, so it passes login as well.
The lint closes the class: auth: basic_auth requires credential.owner to be a
key some role's meta/users.yml declares. Without it a future basic-auth
provider sourced from credentials would hit the same fallback silently. It
imports BASIC_AUTHS from the filter so the rule and the renderer cannot drift
onto different spellings.
Tool names were verified against the adapter version the addon actually
installs, v0.7.0, not the v0.5.0 recorded in meta/mcp.yml: the sanitizer turns
the three registered abilities into infinito-get-post,
infinito-list-categories and infinito-search-posts, matching the rendered
allowlist exactly. Adding login to a discovered entry changes nothing for the
five consumers - three of them do not list basic_auth in supported_auths and
never see this server at all, and the other two read named keys only.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Custom Filter Plugins for Infinito.Nexus
This directory contains custom Ansible filter plugins used within the Infinito.Nexus project.
When to Use a Filter Plugin
- Transform values: Use filters to transform, extract, reformat, or compute values from existing variables or facts.
- Inline data manipulation: Filters are designed for inline use in Jinja2 expressions (in templates, tasks, vars, etc.).
- No external lookups: Filters only operate on data you explicitly pass to them and cannot access external files, the Ansible inventory, or runtime context.
Examples
{{ role_name | entity_name }}
{{ my_list | unique }}
{{ user_email | regex_replace('^(.+)@.*$', '\\1') }}
When not to Use a Filter Plugin
- If you need to load data from an external source (e.g., file, environment, API), use a lookup plugin instead.
- If your logic requires access to inventory, facts, or host-level information that is not passed as a parameter.
Schema 🗺️
How csp_filters.py assembles one application's Content-Security-Policy. Scope is the header build, not the other filters in this directory.
flowchart TD
decl["meta/csp.yml<br/>whitelist, flags, hashes"]
svc["meta/services.yml<br/>services.logout.enabled"]
flags["csp_filters.py:136<br/>get_csp_flags"]
grant["csp_filters.py:354<br/>logout grant"]
wl["csp_filters.py:123<br/>get_csp_whitelist"]
inj["sys-front-inj-dashboard,<br/>-javascript, -matomo, -logout<br/>add_csp_hash"]
gate["csp_filters.py:365<br/>hash gate"]
build["csp_filters.py:203<br/>build_csp_header"]
header["set $csp<br/>nginx vhost"]
decl -->|"1. flags read by"| flags
flags -->|"2. tokens"| build
svc -->|"3. read by"| grant
grant -->|"4. adds 'unsafe-inline'<br/>to script-src-elem and -attr"| build
decl -->|"5. whitelist read by"| wl
wl -->|"6. tokens"| build
inj -->|"7. snippets"| gate
gate -->|"8. hashes, only when<br/>'unsafe-inline' is absent"| build
build -->|"9. joined string"| header
grant -.->|"TRIP-WIRE: the token it adds<br/>closes the gate below, so every<br/>registered hash is discarded"| gate
svc -.->|"TRIP-WIRE: the flag derives from<br/>group_names, so the script policy<br/>follows the round, not the app"| grant
grant -.->|"TRIP-WIRE: absent from the<br/>smart-defaults docstring, which<br/>names logout only for frame-ancestors"| build
Styles carry 'unsafe-inline' by default; scripts do not. The logout grant is the only path that puts it into a script directive.