Miles WardandClaude Fable 5.1
ad3720edbf
Platform-neutral successor to Discord Authenticator, forked from its v0.1.2
state with fresh history. Same vault, same UI, same live-message mechanism —
now behind one `Sink` that speaks three platforms.
Why each platform needs what it needs (this drove the whole settings model):
- Discord: an incoming-webhook URL. Webhooks can edit their own messages.
- Slack: a bot token (xoxb-, scope chat:write) + channel ID. Slack incoming
webhooks can post but never edit, and editing IS the live mechanism, so
chat.postMessage / chat.update via a bot is the only path.
- Telegram: a bot token + chat id. No webhook concept exists. The app detects
the chat id itself from the bot's pending updates ("send /start, then
Detect"), since users rarely know it.
- core: Provider enum; settings hold all three configs so switching back and
forth never re-asks for tokens; per-platform shape validation that names the
common mistakes (xoxp- user token, #name instead of channel ID); a
destination key that clears message ids on platform/channel change but not
on token rotation
- delivery: shared DeliveryError + pacing Governor; Discord client refactored
onto them; new Slack client (classifies Slack's ok:false-on-HTTP-200
errors) and Telegram client ("message is not modified" is success; chat
detection via getUpdates); provider-agnostic message builders — code in a
copyable span everywhere, rollover time as live as each platform allows
- http-api: setup accepts an optional provider; settings PUT/GET carry the
full model; /api/slack/whoami, /api/telegram/whoami, /api/telegram/chats
- webui: three-way optional picker on setup and in Settings → Delivery with
guided per-platform fields; "Check token" (Slack) and "Detect chat"
(Telegram); inline white mark via currentColor
- brand: white mark on the dark plate; blue stays with the Discord sibling
- docs/TEAMS.md: exploration for v0.2 — Teams connectors were disabled May
2026 and Workflows webhooks can't edit, so live tiles need a Bot Framework
bot; options for the inbound endpoint on a homelab and a recommended scope
Verified against mock Discord, Slack and Telegram servers speaking each
platform's real protocol shape: edits target the same message rather than
re-posting, deleted tiles are recovered, dead credentials are surfaced with a
next step, renames refresh without a rollover, and switching platform reposts
on the new one and leaves the old one alone. 138 tests.
Co-Authored-By: Claude Fable 5.1 <[email protected]>
32 lines
1.3 KiB
Bash
Executable File
32 lines
1.3 KiB
Bash
Executable File
#!/bin/sh
|
|
# Fix bind-mount ownership, then drop privileges.
|
|
#
|
|
# Bind-mounted volumes arrive owned by whatever the host says — on Unraid
|
|
# that is typically nobody:users (99:100), and on a plain `docker run -v`
|
|
# it is usually root:root. The service runs as uid 10001 and could not
|
|
# otherwise write the vault, so when we start as root we chown the data
|
|
# directory first and only then hand off.
|
|
#
|
|
# When the container is already running as non-root (some platforms assign
|
|
# their own uid), we skip the chown and exec directly — there is nothing
|
|
# useful we could do about permissions from there anyway.
|
|
set -e
|
|
|
|
OPENMFA_UID=${OPENMFA_UID:-10001}
|
|
OPENMFA_GID=${OPENMFA_GID:-10001}
|
|
DATA_DIR=${OPENMFA_WORK_DIR:-/var/lib/openmfa}
|
|
|
|
if [ "$(id -u)" = "0" ]; then
|
|
mkdir -p "$DATA_DIR"
|
|
chown -R "${OPENMFA_UID}:${OPENMFA_GID}" "$DATA_DIR" 2>/dev/null || true
|
|
# The vault key is the one file that must never be group- or
|
|
# world-readable; a permissive umask on the host can otherwise leave it
|
|
# readable to anyone who can browse the appdata share.
|
|
if [ -f "$DATA_DIR/vault.key" ]; then
|
|
chmod 600 "$DATA_DIR/vault.key" 2>/dev/null || true
|
|
fi
|
|
exec su-exec "${OPENMFA_UID}:${OPENMFA_GID}" /usr/local/bin/openmfa "$@"
|
|
fi
|
|
|
|
exec /usr/local/bin/openmfa "$@"
|