duffyduckandClaude Opus 5
1eb65809ec
Blocker behoben: Ich hatte ein dauerhaftes API-Token vorausgesetzt - das gibt es in OpenCRM nicht. Zugangstoken leben 15 Minuten, der Gegenbuch-Container waere nach dem ersten Durchlauf gestorben. Aufgefallen erst durch die Frage des Betreibers, woher er den Token nimmt. Loesung: Das Gegenbuch meldet sich bei jedem Lauf selbst an, mit einem eigenen Benutzerkonto, dessen Rolle ausschliesslich audit:read traegt. Damit kann es nur Pruefwerte lesen - keine Kundendaten, keine Aenderungen. CRM_TOKEN bleibt fuer Tests moeglich, ist aber nicht mehr der Normalweg. Fehlerfaelle (falsches Passwort, Anmelde-Bremse, CRM nicht erreichbar) werden unterschieden und im Klartext gemeldet. .env.example nennt jetzt zu jedem Schalter die gueltigen Werte - bisher liess sich nur raten, ob es prod oder production heisst. Einschliesslich des Falls "erst nur Staging testen, Prod spaeter dazunehmen". Beide READMEs um "Zugang einrichten" ergaenzt: Rolle mit nur audit:read, Benutzer damit, Zugangsdaten in die .env. Mit dem Hinweis, dass jede Anmeldung im Audit-Log erscheint - gewollt, denn so faellt auch auf, wenn das Gegenbuch aufhoert zu arbeiten. Verifiziert gegen eine Attrappe, die wie das echte CRM eine Anmeldung verlangt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
58 lines
2.1 KiB
YAML
58 lines
2.1 KiB
YAML
# Gegenbuch für OpenCRM
|
||
# =====================
|
||
# Gehört auf einen EIGENEN Rechner – nicht dorthin, wo OpenCRM läuft.
|
||
#
|
||
# Richtung der Verbindung (das ist der eigentliche Schutz):
|
||
# Gegenbuch ──holt lesend──> OpenCRM (HTTPS, Token nur mit audit:read)
|
||
# OpenCRM ─────────────────> (kennt das Gegenbuch nicht)
|
||
#
|
||
# Wer OpenCRM übernimmt, kommt damit nicht an dieses Buch heran. Deshalb holt
|
||
# das Gegenbuch selbst, statt sich etwas schicken zu lassen.
|
||
#
|
||
# Start:
|
||
# cp .env.example .env # Werte eintragen
|
||
# docker compose up -d
|
||
#
|
||
# Zwei Bücher auf einer Maschine sind vorgesehen (Produktion und Test): zwei
|
||
# getrennte Dienste mit getrennten Verzeichnissen und getrennten Schlüsseln.
|
||
# Welche laufen, steuert COMPOSE_PROFILES in der .env.
|
||
|
||
services:
|
||
prod:
|
||
build: .
|
||
container_name: gegenbuch-prod
|
||
restart: unless-stopped
|
||
profiles: ["prod"]
|
||
environment:
|
||
INSTANZ: prod
|
||
CRM_URL: ${PROD_CRM_URL}
|
||
CRM_EMAIL: ${PROD_CRM_EMAIL}
|
||
CRM_PASSWORD: ${PROD_CRM_PASSWORD}
|
||
NOTARY_INTERVAL: ${PROD_INTERVAL:-3600}
|
||
NOTAR_EMAIL: ${NOTAR_EMAIL:-gegenbuch@localhost}
|
||
# Nur beim allerersten Lauf einmalig auf true, danach wieder leeren:
|
||
NOTARY_GENESIS_ACK: ${PROD_GENESIS_ACK:-}
|
||
# Nur nach geklärtem Verlust des Beobachtungsspeichers, siehe README:
|
||
NOTARY_ADOPT_ACK: ${PROD_ADOPT_ACK:-}
|
||
volumes:
|
||
# Buch, Schlüssel, Beobachtungsspeicher und Statusdatei.
|
||
# Dieses Verzeichnis ist das Gegenbuch – es gehört ins Backup.
|
||
- ${PROD_DIR:-./data/prod}:/gegenbuch
|
||
|
||
staging:
|
||
build: .
|
||
container_name: gegenbuch-staging
|
||
restart: unless-stopped
|
||
profiles: ["staging"]
|
||
environment:
|
||
INSTANZ: staging
|
||
CRM_URL: ${STAGING_CRM_URL}
|
||
CRM_EMAIL: ${STAGING_CRM_EMAIL}
|
||
CRM_PASSWORD: ${STAGING_CRM_PASSWORD}
|
||
NOTARY_INTERVAL: ${STAGING_INTERVAL:-3600}
|
||
NOTAR_EMAIL: ${NOTAR_EMAIL:-gegenbuch@localhost}
|
||
NOTARY_GENESIS_ACK: ${STAGING_GENESIS_ACK:-}
|
||
NOTARY_ADOPT_ACK: ${STAGING_ADOPT_ACK:-}
|
||
volumes:
|
||
- ${STAGING_DIR:-./data/staging}:/gegenbuch
|