karim
f518eb7a13
ac7538f chore: gitignore admin/dist build output 86f9f57 core: stage 7 — auth provider (config.auth: supabase | local), DB-less core git-subtree-dir: cms/core git-subtree-split: ac7538fa0c2c883e29fe67c8d8c15c5f40fa2230
30 lines
1.4 KiB
JavaScript
30 lines
1.4 KiB
JavaScript
import { createClient } from '@supabase/supabase-js';
|
|
|
|
const url = process.env.SUPABASE_URL;
|
|
const key = process.env.SUPABASE_SERVICE_KEY;
|
|
|
|
const opts = { auth: { persistSession: false, autoRefreshToken: false } };
|
|
|
|
// Mit Keys: echte Clients. Ohne (DB-loser core, auth:'local'): Clients bleiben
|
|
// null; die Aufrufer (auth/stats/users) sind null-sicher und nutzen den lokalen
|
|
// Provider. DB-Plugins (dialog) laufen ohnehin nur mit Supabase. Den Fail-Fast
|
|
// für auth:'supabase' macht index.js (das kennt die config) — supabase.js bleibt
|
|
// bewusst config-frei, damit Unit-Tests es ohne CMS_CONFIG importieren können.
|
|
let _supabase = null;
|
|
let _supabaseAuth = null;
|
|
if (url && key) {
|
|
// Daten-Client: Service-Role-Key, umgeht RLS. NUR für DB-Zugriffe (from/insert/…).
|
|
// Wichtig: hier niemals signInWithPassword aufrufen — das schaltet den
|
|
// Authorization-Header des Clients prozessweit auf das User-Token um (SIGNED_IN),
|
|
// wodurch anschließende Inserts als role=authenticated laufen und an RLS scheitern.
|
|
_supabase = createClient(url, key, opts);
|
|
// Eigener Client nur für Auth (Login, Token-Prüfung). Getrennt, damit ein
|
|
// signInWithPassword den Daten-Client oben nicht „vergiftet". Niemals ins Frontend.
|
|
_supabaseAuth = createClient(url, key, opts);
|
|
} else {
|
|
console.warn('supabase.js: kein SUPABASE_URL/SERVICE_KEY — DB-loser Betrieb (auth: local erwartet).');
|
|
}
|
|
|
|
export const supabase = _supabase;
|
|
export const supabaseAuth = _supabaseAuth;
|