Skip to content

Let Periphery send extra websocket headers to Core from a file - #1649

Open
AzScep wants to merge 1 commit into
moghtech:mainfrom
AzScep:azscep/periphery-core-headers-file
Open

AzScep wants to merge 1 commit into
moghtech:mainfrom
AzScep:azscep/periphery-core-headers-file

Conversation

@AzScep

@AzScep AzScep commented Sep 26, 2026

Copy link
Copy Markdown

Problem

In outbound mode Periphery opens a websocket to Core, but it has no way to add headers to that request. So it can't get through an authenticating reverse proxy in front of Core. For example, with Cloudflare Access protecting the whole Core hostname, a client has to send CF-Access-Client-Id and CF-Access-Client-Secret service token headers. Today the only option is a bypass rule for /ws/periphery.

Change

  • New Periphery setting core_headers_file (PERIPHERY_CORE_HEADERS_FILE). It points to a file with one Name: value header per line, which is added to the websocket upgrade request. Blank lines and # comments are ignored. An empty env value counts as unset.
  • The file is read again on every connection attempt, so rotated values take effect on the next reconnect without a restart.
  • Periphery refuses to start if the file is missing, has no headers or an invalid line, isn't owned by the user Periphery runs as, or can be accessed by group or others (chmod 600).
  • Header values are secrets: they are marked sensitive and never appear in error messages or logs. Headers that the websocket handshake sets itself (Host, Connection, Upgrade, Sec-WebSocket-* and so on) are rejected.
  • TungsteniteWebsocket::connect* in lib/transport now takes an extra HeaderMap. Core passes an empty one, so its behaviour doesn't change.
  • The setting is documented in config/periphery.config.toml.

This keeps the header values out of the main config and env. Only the file path goes there, and it shows up in the sanitized startup config.

Verification

  • 8 unit tests in connection::headers::tests cover parsing, values never showing up in errors or Debug output, and the mode and owner checks.
  • cargo fmt --check passes and clippy is clean for komodo_periphery, transport and komodo_core.
  • End to end: I ran a 2.3.3 Core (official image, Mongo) behind a Caddy proxy that returns 403 unless both headers match, with Periphery built from this branch:
    • no file: every attempt gets 403 and there is no login
    • file mode 644: Periphery exits at startup with an error telling you to chmod 600
    • file mode 600: Periphery logs in to Core through the proxy
    • file changed to a wrong value and the proxy restarted: reconnects get 403
    • correct value restored: Periphery reconnects without a restart
    • at debug log level, no header value appears in any Periphery log

馃 Generated with Claude Code

Periphery's outbound websocket cannot pass an authenticating reverse
proxy in front of Core, such as Cloudflare Access, which expects
service token headers on the upgrade request.

- Add `core_headers_file` (PERIPHERY_CORE_HEADERS_FILE): a file of
  `Name: value` lines sent with the websocket request to Core.
  Blank lines and `#` comments are ignored; an empty env value is unset.
- The file is re-read on every connection attempt, so rotated values
  apply on reconnect.
- Periphery refuses to start if the file is missing, invalid, not owned
  by its user, or accessible by group or others.
- Values are marked sensitive and never included in errors or logs.
  Headers owned by the websocket handshake are rejected.
- The transport's websocket connect takes extra headers; Core passes none.

Verified end to end with a 2.3.3 Core behind a proxy that returns 403
unless the headers match: no file gets 403, a 644 file stops startup,
a 600 file connects, a rotated wrong value fails on reconnect and the
restored value reconnects without a restart, and no value is logged.
AzScep added a commit to AzScep/komodo that referenced this pull request Sep 26, 2026
Adds the core_headers_file patch (moghtech#1649) to PATCHES.md and
bumps FORK_REVISION so the image publishes as 2.3.3-azscep.2.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant