Die Adresse im <script>-Tag stand fest in der index.html, waehrend die CSP
aus HONEYBAR_ORIGIN kam. Wer die Leiste woanders betreibt, bekam genau den
Widerspruch: die CSP erlaubte den eigenen Ursprung, geladen wurde der alte.
Der erste Versuch, das ueber ein Bau-Argument zu loesen, half beim fertigen
Abbild nicht — dort ist der Bau vorbei, und ein Umzug haette einen Neubau
verlangt. Ursprung und Schluessel stehen jetzt in /api/v1/public/config, die
Oberflaeche haengt das Skript selbst ein. Beides speist sich aus derselben
Variablen wie die CSP, sie koennen also nicht auseinanderlaufen, und eine
Aenderung wirkt beim Neustart.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Adresse im <script>-Tag stand fest im Quelltext, waehrend die CSP aus
HONEYBAR_ORIGIN kam. Wer die Leiste woanders betreibt, bekam genau den
Widerspruch: die CSP erlaubte den eigenen Ursprung, geladen wurde der alte.
Beides speist sich jetzt aus derselben Variablen. Ist sie leer, nimmt
vite.config.ts den Tag ganz heraus — sonst bliebe src="/honeybar/honeybar.js"
stehen und der Service Worker beantwortete das mit index.html.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
HoneyOS liegt auf einer anderen Site als Aether – duckdns.org steht auf der
Public-Suffix-Liste, die gemeinsame Endung zaehlt fuer den Browser also
nicht. Folge: bei der Anfrage der Leiste schickt er die HoneyOS-Sitzung
nicht mit, und ohne zweiten Ausweis bekaeme sie nie eine App-Liste.
- data-key kommt aus HONEYBAR_KEY in der .env und wird beim Bauen von Vite
in die index.html eingesetzt. Bewusst nicht im Quelltext: er kaeme sonst
ins Repo und liesse sich nur mit einer Code-Aenderung wechseln.
- Leer gebaut heisst data-key="" – die Leiste bekommt dann keine Liste,
Aether bleibt davon unberuehrt.
Nach einer Aenderung an HONEYBAR_KEY ist ein `build app` noetig, ein
Neustart genuegt nicht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Nach dem Hin und Her um Profile, Ports und Escaping war Sediment
liegengeblieben:
- README: "Drei Adressen fuer drei Richtungen" stand zweimal; die
Profil-Erklaerung war eine Chronik ("das war nicht immer so") statt
einer Anleitung. Jetzt ein Absatz.
- .env.example (beide): der Office-Block begann mit einem Hinweis auf
COMPOSE_PROFILES, den man nur braucht, wenn man selbst ein Profil
anlegt - als erste Zeile eines Abschnitts unbrauchbar. Raus.
- TESTING: der grosse Office-Abschnitt behauptete noch "Getestet mit
Collabora im Compose-Profil office" und pruefte "ohne --profile startet
der Container nicht". Beides ueberholt.
- Umlaute vereinheitlicht (laeuft neben gehoert), $-Hinweis von vier auf
zwei Zeilen.
Dazu zwei neue Zeilen in der Fehlertabelle des README: Container entsteht
gar nicht (Profil) und Container laeuft, aber kein Menuepunkt (leerer
OFFICE_PROVIDER oder falscher Port).
Geprueft: beide Compose-Dateien gueltig, jeder Schluessel aus dem Code
steht in deploy/.env.example, keine doppelten Absaetze mehr.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
profiles: [office] war als Sparmassnahme gedacht: Der Container laeuft nur
auf Wunsch. In Portainer/Dockge/Komodo gibt es aber kein --profile, und der
Dienst entstand dort nie – ohne Fehlermeldung, ohne Hinweis, ohne Weg ueber
die Bedienung.
Eine Voreinstellung, bei der das Einfuegen des Schnipsels nichts bewirkt,
ist die falsche. Alle drei Schnipsel starten jetzt mit (geprueft: app office postgres). Abschalten: docker compose stop
office. Wer ein Profil will, haengt die Zeile selbst an.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Port war fest auf 127.0.0.1 gebunden. Richtig, solange ein Reverse
Proxy davorsteht – beim Ausprobieren in einer Testumgebung heißt es aber
ERR_CONNECTION_REFUSED, sobald man über die IP zugreift, und nichts im
Log deutet darauf hin: Der Kernel lehnt ab, bevor die Anwendung etwas
davon sieht.
APP_BIND ist jetzt eine Variable, Vorgabe bleibt 127.0.0.1. Gilt für die
App und für die Office-Container in allen drei README-Schnipseln.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das Compose in deploy/ war zu über der Hälfte Kommentar (73 von 137
Zeilen) und mischte zwei Zwecke. Jetzt getrennt:
Wurzel docker-compose.example.yml + .env.example – betreiben,
zieht das fertige Abbild, braucht keinen Quelltext
deploy/ docker-compose.yml + .env.example – entwickeln,
baut aus dem Quelltext, kennt alle Schalter
Die schlanke .env.example führt nur die Pflichtwerte und Office; die
vollständige Liste mit Erklärungen bleibt in deploy/.env.example.
Die kopierte /docker-compose.yml ist ignoriert – sie gehört in die
Umgebung, nicht ins Repo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Das Abbild lag zuerst unter gitea…/honey/aether – also beim Nutzer statt
bei der Organisation, unter der die anderen Docker-Projekte liegen. Neuer
Pfad: gitea…/docker/aether, gleicher Digest. Das alte Paket ist gelöscht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Go-Backend (chi, pgx, golang-migrate) + React/TS-Frontend als PWA.
Enthalten: Auth inkl. OIDC, Dateien mit Versionen und Papierkorb,
Freigaben (Links + intern), WebDAV, Gruppenordner, Admin/Theming,
Volltextsuche mit OCR, eigener PDF-Betrachter und WOPI-Office
(Collabora/OnlyOffice).
Nicht im Repo: deploy/.env (Sitzungsschlüssel, DB- und Admin-Passwort)
sowie alle Daten- und Build-Verzeichnisse – siehe .gitignore.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
HoneyandClaude Opus 5