Einstellungen strikt pro Benutzer: kein process.env-Fallback mehr
config.get() ist bei einem nicht gesetzten Schluessel auf process.env zurueckgefallen. Da die Env-Variablen die Konfiguration des Admins enthalten (Docker-Env: MAIL_*, CALDAV_URL, OLLAMA_API_KEY, API_TOKEN), hat damit JEDER neu angelegte Benutzer ohne eigene Einstellungen stillschweigend die Zugangsdaten des Admins geerbt: - /einstellungen zeigte ihm die Zugangsdaten des Admins an. - mailer/caldav isConfigured() war true -> der IMAP-Poller hat fuer den neuen Benutzer das Postfach des Admins abgerufen und dessen E-Mails in sein Konto einsortiert; CalDAV synchronisierte den Kalender des Admins. - Der bezahlte Ollama-Key des Admins wurde mitbenutzt. Jetzt: - config.get() loest ausschliesslich die Zeilen des aktuellen Benutzers auf, sonst den eingebauten Standard (nicht-geheime Werte wie Modell, Host, Ports, Intervalle). Alle Credentials sind bei neuen Benutzern leer, d. h. Ollama/E-Mail/CalDAV/API sind fuer sie aus, bis sie sich selbst etwas eintragen. - Noch per Env gesetzte Konfiguration wird einmalig in die Zeilen des ADMIN uebernommen (importEnvIntoAdmin, Aufruf beim Boot nachdem app_state existiert - in runMigration war das bei Neuinstallationen ein No-op, weil die Tabelle dort noch nicht angelegt ist). - config.ensureLoaded(user.id) beim Aufloesen der Session bzw. des X-API-Key. config.get() ist synchron und liest den Per-User-Cache; ohne Warmladen las ein Web-Request die Werte als "nicht konfiguriert". Das hat bisher der env-Fallback verdeckt (er hielt zufaellig die Werte des Admins) - ohne ihn muss die Config pro Request wirklich geladen werden. Verifiziert gegen eine Kopie der Produktions-DB mit Sentinel-Env-Werten: Admin behaelt seine kompletten Einstellungen, der zweite Benutzer sieht ueberall leere Credentials, Mail/CalDAV sind fuer ihn inaktiv, und der Env-API-Token wird nicht mehr als gueltiger X-API-Key akzeptiert. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -14,6 +14,7 @@ const blacklist = require('./blacklist');
|
||||
const { LABEL_OPTIONS, parseLabels, serializeLabels } = require('./labels');
|
||||
const { normalizeDokumente } = require('./documents');
|
||||
const { userContext, currentUserId } = require('./context');
|
||||
const config = require('./config');
|
||||
|
||||
const CONFIG_PREFIX = 'cfg:';
|
||||
|
||||
@@ -76,6 +77,11 @@ function createExternalApi(deps) {
|
||||
return res.status(401).json({ error: 'Ungültiger oder fehlender API-Key (Header: X-API-Key).' });
|
||||
}
|
||||
req.user = user;
|
||||
// Warm this user's cfg rows: config.get() is synchronous and reads from
|
||||
// the per-user cache, so without this an API request could see the user
|
||||
// as unconfigured (e.g. no Ollama key) purely because nothing had loaded
|
||||
// their rows yet in this process.
|
||||
await config.ensureLoaded(user.id);
|
||||
// Run the remainder of the request inside this user's context so
|
||||
// currentUserId() / config.get() / the scoped helpers all resolve here.
|
||||
userContext.run(user, next);
|
||||
|
||||
Reference in New Issue
Block a user