Hoppa till huvudinnehåll

Autentisering och säkerhet

Libre WebUI använder lokala användarkonton med JWT-sessioner. En ny installation tillåter alltid att en lokal administratör skapas. Offentlig registrering för senare lokala konton och OAuth-konton är stängd som standard.

Förstagångskonfiguration​

När databasen saknar användare:

  1. Libre WebUI visar förstagångskonfigurationen.
  2. Användaren skapar det första lokala kontot.
  3. Kontot tilldelas rollen admin.
  4. Senare offentlig registrering förblir stängd om den inte uttryckligen aktiveras.

Befintliga databaser behåller nuvarande användare och roller.

Lokala konton​

Lokal registrering kräver:

  • Användarnamn
  • Lösenord mellan 12 tecken och 72 UTF-8-byte, med versal, gemen och siffra
  • Valfri e-postadress

Lösenord hashas med bcrypt före lagring. Inloggnings- och registreringsrutter är hastighetsbegränsade.

Godkännande av registrering​

Offentlig registrering ger inte åtkomst i sig. Varje konto som skapas genom formuläret eller en OAuth-leverantör börjar i läget pending och måste godkännas av en administratör innan inloggning.

Undantaget är startkontot: det första riktiga kontot i en tom databas skapas atomärt som active med rollen admin, så en ny installation får en fungerande administratör. Alla senare registreringar väntar på granskning.

Vad en väntande användare ser:

  • Registreringen lyckas men returnerar ingen sessionstoken. API:t svarar 202 med approvalRequired: true och UI:t förklarar att en administratör måste godkänna kontot.
  • Inloggning med korrekt lösenord nekas med 403 och koden ACCOUNT_PENDING ("Ditt konto väntar på administratörens godkännande"). OAuth-inloggning omdirigeras till inloggningssidan med ?approval=pending.
  • Kontostatus läses om från databasen vid varje autentiserad begäran, så en session kan aldrig överleva kontots status active.

Vad en administratör ser:

  • Användarhanteringen visar kortet Väntande godkännanden med väntande konton, åtgärden Aktivera konto och en avvisningsåtgärd. Avvisning innebär borttagning; något separat avstängt läge finns inte.
  • Inloggade administratörer meddelas i appen med en markering vid Användare och ett popupmeddelande vid nya registreringar. Sammanfattningen av väntande godkännanden avsöks ungefär en gång per minut (GET /api/users/pending-approvals, endast administratörer).
  • Godkännande (PATCH /api/users/:id/approve, endast administratörer) registrerar vem som godkände kontot och när. Rollen ändras inte: kontot behåller rollen user tills en administratör befordrar det. Godkännandet gäller vid nästa inloggningsförsök; inget behöver skapas om.

Befintliga konton påverkas inte av en uppgradering. Endast konton som skapas genom offentlig registrering efter att funktionen infördes börjar som väntande. Konton som en administratör skapar är aktiva direkt.

Aktivera offentlig registrering avsiktligt​

Registrering är inaktiverad som standard. Ange backendvariabeln nedan endast under den period då nya lokala eller OAuth-konton ska godtas:

ENABLE_SIGNUP=true

Återställ den till false efter det planerade registreringsfönstret. Befintliga lokala och OAuth-användare kan fortfarande logga in och administratörer kan skapa konton medan offentlig registrering är stängd.

En tom databas tillåter alltid en lokal administratör även när ENABLE_SIGNUP=false; OAuth kan inte ta startplatsen. Placera värdnamnet bakom en identitetstillåtelselista som Cloudflare Access före start vid en privat fjärrdriftsättning och skapa sedan den första administratören genom den skyddade rutten.

Roller​

RollSyfte
adminInstansadministration, användarhantering, systeminställningar och betrodd Work-runtime
userVanliga arbetsflöden för chatt, modell, persona, dokument och inställningar

Installation, borttagning, kopiering, push och avlastning av modeller begränsas till administratörer eftersom de ändrar värdresurser.

Work-åtkomst​

Work är som standard begränsat till administratörer eftersom en vald modell kan köra godtyckliga kommandon i en hanterad container. En administratör kan öppna Work för alla aktiva användare från fliken Användarhantering i Inställningar. Inställningen består efter omstart och gäller omedelbart, även för öppna terminalsessioner. Arbetsytor med värdmappar förblir administratörsexklusiva eftersom de bind-monterar serversökvägar. Behandla alla med Work-åtkomst som betrodda runtimeoperatörer, inte enbart WebUI-användare.

Administratörsbehörighet kontrolleras mot aktuell databasroll, inte bara JWT-cachen. En nedgradering återkallar därför Work-åtkomst omedelbart. Backend försöker avbryta aktiva körningar och stoppa användarens Work-containrar och förhandsvisningar men behåller uppgiftsregister och namngivna volymer. Om Docker-rensningen misslyckas förblir åtkomsten återkallad, rolländringen rapporterar felet och operatören måste återställa Docker-åtkomst och försöka igen.

Att ta bort en användare förstör dennes Work-data. Libre WebUI stoppar först hanterade containrar och tar bort Work-volymer, därefter konto och databasposter. Om Docker inte kan bevisa att rensningen lyckades misslyckas kontoborttagningen så att en administratör kan rätta runtimeproblemet och försöka igen.

Grupper och resursbehörigheter​

Administratörer kan skapa grupper och hantera medlemskap. Grupper är huvudmän för resursbehörigheter: ägaren av en chatt, anteckning, dokument, kunskapssamling, mapp, persona, prompt, färdighet eller kalender kan ge read, write eller admin till en användare eller grupp genom åtkomst-API:t. Alla delningsbara ytor använder samma dialogruta (se Delning), och verktygsservrar kan avgränsas likadant. Resurser förblir privata som standard; den globala rollen admin ger inte åtkomst till andras innehåll. Medlemskap utvärderas vid begäran, så borttagning återkallar gruppåtkomst direkt. Vyn "effektiv åtkomst" förklarar varför en användare har åtkomst genom att lista roll, grupper, funktionsåtkomst och alla behörigheter.

Säkerhetsrevisionslogg​

Säkerhetskänsliga åtgärder—lyckade och misslyckade inloggningar, utloggningar, återkallade sessioner och token samt ändringar av användare, grupper, behörigheter och token—registreras i en separat revisionslogg som endast kan utökas. Detaljer maskeras före lagring: hemlighetsliknande nycklar tas bort och payloadstorlekar begränsas, så lösenord, token och promptinnehåll hamnar aldrig i loggen. Grupp- och behörighetsändringar skriver revisionshändelsen i samma databastransaktion. Standardlagring är 180 dagar (AUDIT_RETENTION_DAYS).

Sessioner​

Backend signerar JWT med JWT_SECRET. Ange en stabil hemlighet i produktion:

JWT_SECRET=replace-with-a-long-random-secret

Ändrad JWT_SECRET ogiltigförklarar befintliga sessioner. Lokala och OAuth-inloggningstoken använder JWT_EXPIRES_IN, standard 7d; ändringen påverkar nya sessioner. WebSocket-anslutningar byter den beständiga token mot en kortlivad engångsbiljett och stängs när den underliggande sessionen löper ut.

Varje inloggning skapar även en serversessionspost som binds i JWT. Inställningar → Sessioner listar enheter, inloggningsmetod, första och senaste aktivitet samt utgångstid. Återkallning eller Logga ut andra sessioner ogiltigförklarar token omedelbart på alla repliker och stänger aktiva WebSocket-anslutningar. Äldre token utan sessions-ID förblir giltiga till utgång, men åtgärden från en ny inloggning anger även en kontogräns som avvisar dem.

Tvåfaktorsautentisering och passkeys​

Inställningar → Sessioner hanterar både andrafaktorer och lösenordsfri inloggning:

  • Autentiseringsapp (TOTP). Registreringen visar en base32-hemlighet och en otpauth://-länk för valfri autentiseringsapp. Den första sexsiffriga koden aktiverar funktionen och visar tio engångsåterställningskoder. Därefter returnerar lösenordsinloggning en kortlivad utmaning i stället för en session, och POST /api/auth/mfa/verify slutför inloggningen med TOTP- eller återställningskod. Tidssteget för varje accepterad kod registreras så att koden inte kan återspelas. Återställningskoder lagras endast som nycklade envägsuppslagstoken och fungerar exakt en gång. Inaktivering eller nya koder kräver att faktorn bevisas igen.
  • Passkeys (WebAuthn). Logga in med passkey utför lösenordsfri inloggning med en identifierbar autentiseringsuppgift. Användarverifiering via skärmlås, biometri eller PIN krävs vid registrering och inloggning. Attestation accepteras som none, ES256 och EdDSA stöds och autentiseringsmaterial krypteras vid lagring med ID:t som nycklad uppslagstoken. Utmaningar används en gång och löper ut efter fem minuter; en signaturräknare som inte ökar avvisas som klonsignal. Passkeys kräver säker HTTPS-origin eller localhost under utveckling. Ange WEBAUTHN_RP_ID vid flera värdnamn.

MFA-utmaningstoken efter korrekt lösenord signeras med en hemlighet som härletts från men skiljer sig från JWT_SECRET. Den kan aldrig autentisera en API-begäran, binds till ett konto och syfte och förbrukas när den lyckas.

Administratörer kan kräva en andra faktor för alla konton (Användare → tvåfaktorspolicykortet eller MFA_REQUIRED_MODE=required). Användare utan faktor leds genom registreringen vid nästa inloggning före sessionsutfärdande. Administratörer kan återställa TOTP för kontoåterställning; passkeys lämnas eftersom användaren hanterar dem. Registrering, aktivering, verifieringsfel, inaktivering, policyändringar, passkey-tillägg/borttagning och administratörsåterställningar revisionsloggas.

MFA gäller lösenordsinloggningar. OAuth och OIDC förlitar sig på identitetsleverantörens andrafaktor och utmanas inte igen. API-token påverkas inte eftersom de aldrig använder sessionsautentisering.

API-token​

Inställningar → API-nycklar skapar personliga åtkomsttoken med prefixet lwk_. Hemligheten visas en gång och lagras endast som hash. Varje token har en uttrycklig omfångslista (chat, models, documents, notes, personas, media, work, admin); backend mappar varje ruttfamilj till ett omfång, så en anteckningstoken kan inte nå chattar eller administration och sessionshantering är aldrig nåbar med token. Token stöder valfri utgångstid, spårar senaste användning, kan återkallas och hastighetsbegränsas per token över repliker. Admin-token kan endast skapas av administratörer och kräver fortfarande adminroll vid användning. En token med chat är även nyckeln till det OpenAI-kompatibla offentliga /v1-API:t.

Cloudflare Turnstile​

Turnstile skyddar lösenordsinloggning och registrering när båda nycklarna är konfigurerade:

TURNSTILE_SITE_KEY=...
TURNSTILE_SECRET_KEY=...
TURNSTILE_EXPECTED_HOSTNAME=chat.example.com

Frontend tilldelar separata åtgärder login och signup. Backend verifierar token med Cloudflare och avvisar ett svar vars värdnamn eller åtgärd inte matchar. BASE_URL anger förväntat värdnamn när TURNSTILE_EXPECTED_HOSTNAME inte anges.

Om någon nyckel saknas inaktiveras Turnstile.

GitHub OAuth​

Konfigurera:

GITHUB_CLIENT_ID=...
GITHUB_CLIENT_SECRET=...
GITHUB_CALLBACK_URL=https://your-domain.example/api/auth/oauth/github/callback

GitHub OAuth skapar lokala användare med användarnamn som börjar med gh_ och rollen user som standard.

Hugging Face OAuth​

Konfigurera:

HUGGINGFACE_CLIENT_ID=...
HUGGINGFACE_CLIENT_SECRET=...
HUGGINGFACE_CALLBACK_URL=https://your-domain.example/api/auth/oauth/huggingface/callback

Hugging Face OAuth skapar lokala användare med användarnamn som börjar med hf_ och rollen user som standard.

Båda OAuth-leverantörerna använder ett kryptografiskt slumpmässigt state bundet till en kortlivad HttpOnly-, SameSite-cookie. Callbacken avvisar saknat eller avvikande tillstånd. Efter lyckad callback återförs JWT i en 60-sekunders HttpOnly-cookie som byts och rensas omedelbart; bearer-token placeras aldrig i callback-URL:er, historik eller referrer-huvuden.

Omdirigeringar och CORS​

Ange BASE_URL för callbackstandard och CORS_ORIGIN för webbläsaråtkomst:

BASE_URL=https://your-domain.example
CORS_ORIGIN=https://your-domain.example

Inkludera Vites utvecklingsorigin vid lokal utveckling:

CORS_ORIGIN=http://localhost:5173,http://127.0.0.1:5173

Demoläge​

Demoläget är ett förhandsvisningsläge i frontend. Det förifyller inaktiverade demouppgifter och använder simulerade API-svar. Det är inte autentisering för produktion.

Säkerhetschecklista​

  • Ange en stark JWT_SECRET.
  • Behåll DATA_DIR på beständig, åtkomstkontrollerad lagring.
  • Säkerhetskopiera ENCRYPTION_KEY med databasen.
  • Konfigurera Turnstile för offentlig registrering.
  • Använd HTTPS för offentliga driftsättningar.
  • Begränsa leverantörsnycklar till minsta nödvändiga omfång.
  • Håll OAuth-callback-URL:er exakta.
  • Ge Work-åtkomst endast till personer som är betrodda att använda backendens containerruntime.

Relaterad dokumentation​