मुख्य कंटेंट तक स्किप करें

प्रमाणीकरण और सुरक्षा

Libre WebUI JWT सत्र वाले स्थानीय खाते उपयोग करता है। नई स्थापना हमेशा एक स्थानीय व्यवस्थापक प्रारंभ करने देती है; आगे की सार्वजनिक स्थानीय/OAuth पंजीकरण डिफ़ॉल्ट बंद है।

पहली बार सेटअप​

खाली डेटाबेस में:

  1. प्रारंभिक प्रवाह दिखता है।
  2. पहला स्थानीय खाता बनता है।
  3. उसे admin भूमिका मिलती है।
  4. आगे की पंजीकरण स्पष्ट रूप से खोलने तक बंद रहती है।

मौजूदा डेटाबेस उपयोगकर्ता और भूमिकाएँ रखते हैं।

स्थानीय खाते​

  • उपयोगकर्ता नाम
  • 12 अक्षर से 72 UTF-8 बाइट का पासवर्ड, बड़े/छोटे अक्षर और संख्या सहित
  • वैकल्पिक ईमेल

पासवर्ड bcrypt से हैश होते हैं। लॉगिन और पंजीकरण routes rate-limited हैं।

पंजीकरण स्वीकृति​

सार्वजनिक पंजीकरण स्वयं प्रवेश नहीं देता। Form या OAuth से बना खाता pending शुरू होता और व्यवस्थापक स्वीकृति चाहता है। खाली डेटाबेस का पहला असली खाता परमाणु रूप से active और admin बनता है; बाकी प्रतीक्षा करते हैं।

लंबित उपयोगकर्ता:

  • सफल पंजीकरण, सत्र टोकन नहीं; API 202, approvalRequired: true।
  • सही पासवर्ड भी 403, ACCOUNT_PENDING ("Your account is waiting for administrator approval"); OAuth ?approval=pending।
  • हर authenticated अनुरोध पर स्थिति database से फिर पढ़ा जाता है।

व्यवस्थापक:

  • लंबित approvals कार्ड में Activate खाता और reject; rejection deletion है।
  • उपयोगकर्ता badge और toast; GET /api/users/pending-approvals लगभग प्रति मिनट।
  • PATCH /api/users/:id/approve approver/समय दर्ज करता, भूमिका नहीं बदलता; user अगले login में सक्रिय।

Upgrade मौजूदा खातों को प्रभावित नहीं करता। व्यवस्थापक-बनाया खाता तुरंत सक्रिय।

सार्वजनिक पंजीकरण जानबूझकर खोलना​

ENABLE_SIGNUP=true

विंडो के बाद false करें। मौजूदा उपयोगकर्ता login और व्यवस्थापक खाता बनाएँ कर सकते हैं। खाली database ENABLE_SIGNUP=false में भी एक स्थानीय व्यवस्थापक देता है; OAuth bootstrap नहीं ले सकता। निजी दूरस्थ डिप्लॉयमेंट में पहले Cloudflare Access जैसी identity allowlist लगाएँ।

भूमिकाएँ​

भूमिकाउद्देश्य
adminInstance, उपयोगकर्ता, system सेटिंग और विश्वसनीय Work रनटाइम ऑपरेशन
userसामान्य chat, मॉडल, persona, दस्तावेज़ और सेटिंग

मॉडल स्थापित/हटाएँ/copy/push/unload host संसाधन बदलते हैं, केवल व्यवस्थापक।

Work पहुँच​

Work डिफ़ॉल्ट व्यवस्थापक-केवल क्योंकि मॉडल managed container में arbitrary commands चलाता है। व्यवस्थापक इसे सेटिंग्स > उपयोगकर्ता प्रबंधन टैब से सभी सक्रिय उपयोगकर्ता को खोल सकता; setting स्थायी और तुरंत खोलें terminals में लागू। Host-फ़ोल्डर workspaces हमेशा व्यवस्थापक-केवल। हर Work उपयोगकर्ता को विश्वसनीय रनटाइम operator मानें।

Authorization वर्तमान DB भूमिका से, केवल cached JWT नहीं। Demotion तुरंत access वापस लें, बैकएंड चलाता है abort और containers/previews रोकें करने का प्रयास, records/volumes preserve। Docker cleanup विफलता access वापस नहीं देता, भूमिका बदलाव त्रुटि report करता है।

उपयोगकर्ता deletion उसके Work डेटा के लिए destructive: पहले containers/volumes, फिर खाता/DB। Cleanup prove न हो तो deletion fail ताकि फिर प्रयास हो।

समूह और संसाधन अनुमतियाँ​

व्यवस्थापक groups और memberships बनाता है। Chat, note, दस्तावेज़, knowledge संग्रह, फ़ोल्डर, persona, prompt, skill या calendar मालिक उपयोगकर्ता/समूह को read, write, admin साझा dialog से देता है (Sharing); tool servers भी। संसाधन डिफ़ॉल्ट निजी; वैश्विक admin दूसरों का सामग्री नहीं खोलता। Membership अनुरोध समय पर, removal तुरंत वापस लें। सेटिंग्स > उपयोगकर्ता प्रबंधन टैब का effective access दृश्य भूमिका, groups, सुविधा access और grants समझाता है।

सुरक्षा ऑडिट लॉग​

Login/विफलता/logout, session/टोकन revocation, उपयोगकर्ता/समूह/grant/टोकन बदलाव append-केवल ऑडिट लॉग में usage analytics से अलग। रहस्य-like keys हटते, payload सीमित, इसलिए password/टोकन/prompt नहीं। समूह/grant घटना समान transaction। व्यवस्थापक सेटिंग्स > उपयोगकर्ता प्रबंधन टैब से क्वेरी करता; डिफ़ॉल्ट 180 दिन (AUDIT_RETENTION_DAYS)।

सत्र​

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

JWT_SECRET बदलना sessions अमान्य करता है। स्थानीय/OAuth tokens JWT_EXPIRES_IN, डिफ़ॉल्ट 7d। WebSocket टिकाऊ टोकन को अल्पकालिक एकबारगी ticket में बदलकर session expiry पर बंद होता है।

हर login सर्वर-side session record JWT में bind करता है। सेटिंग → Sessions डिवाइस, विधि, activity, expiry दिखाता है। वापस लें या “Sign बाहर अन्य sessions” टोकन तुरंत सभी replicas पर अमान्य और WebSocket बंद करता है। पुराने sid-कम टोकन expiry तक, लेकिन fresh login cutoff stamp कर सकता है।

दो-कारक और पासकी​

  • Authenticator (TOTP). Base32 रहस्य और otpauth://; पहला 6-digit code activate कर दस one-समय recovery codes दिखाता है। फिर password short challenge लौटाता और POST /api/auth/mfa/verify TOTP/recovery से पूरा। Timestep replay रोकने को record, recovery keyed one-way और once। Disable/regenerate factor फिर prove।
  • Passkeys (WebAuthn). Discoverable क्रेडेंशियल से passwordless login; registration/login में screen lock, biometric या PIN। Attestation none, ES256/EdDSA, material एन्क्रिप्टेड, ID keyed lookup। Challenge once और five मिनट; nonzero counter न बढ़े तो clone signal। HTTPS या dev localhost; कई hostnames के लिए WEBAUTHN_RP_ID।

MFA challenge सही password के बाद JWT_SECRET से derived लेकिन अलग रहस्य से signed; API auth नहीं, one खाता/उद्देश्य और सफलता पर consumed।

व्यवस्थापक कार्ड या MFA_REQUIRED_MODE=required से सभी पर factor माँग सकता। बिना factor उपयोगकर्ता अगली login में enroll करता। व्यवस्थापक TOTP रीसेट कर सकता; passkeys उपयोगकर्ता-managed। सभी घटनाएँ ऑडिट लॉग।

MFA password login पर; OAuth/OIDC प्रदाता factor पर भरोसा, API tokens अप्रभावित।

API टोकन​

सेटिंग → API keys lwk_ prefix personal tokens बनाता है। रहस्य once दिखता और हैश मात्र। Scopes (chat, models, documents, notes, personas, media, work, admin) रूट family सीमित करते; session management टोकन से नहीं। वैकल्पिक expiry, अंतिम use, वापस लें, replica-wide rate सीमा। admin केवल व्यवस्थापक बनाता और उपयोग में भूमिका चाहिए। chat सार्वजनिक /v1 API कुंजी है।

Cloudflare Turnstile​

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

फ़्रंटएंड अलग login/signup कार्रवाइयाँ देता। बैकएंड Cloudflare से टोकन, hostname और कार्रवाई verify। TURNSTILE_EXPECTED_HOSTNAME न हो तो BASE_URL; कोई कुंजी अनुपस्थित तो अक्षम।

GitHub OAuth​

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

gh_ prefix स्थानीय user बनाता है।

Hugging Face OAuth​

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

hf_ prefix स्थानीय user। दोनों प्रदाता यादृच्छिक state short HttpOnly SameSite cookie से bind करते। Callback mismatch reject। सफलता JWT 60-second HttpOnly cookie से फ़्रंटएंड में exchange/साफ़; bearer URL/इतिहास/referrer में नहीं।

Redirect और CORS​

Callback defaults के लिए BASE_URL, ब्राउज़र access के लिए CORS_ORIGIN:

BASE_URL=https://your-domain.example
CORS_ORIGIN=https://your-domain.example
CORS_ORIGIN=http://localhost:5173,http://127.0.0.1:5173

Demo मोड​

अक्षम demo क्रेडेंशियल और mock API वाला फ़्रंटएंड preview है, production authentication नहीं।

सुरक्षा सूची​

  • मजबूत JWT_SECRET
  • स्थायी access-controlled DATA_DIR
  • Database के साथ ENCRYPTION_KEY backup
  • सार्वजनिक signup पर Turnstile
  • सार्वजनिक deployment में HTTPS
  • प्रदाता keys न्यूनतम दायरा
  • सटीक OAuth callback URLs
  • Work केवल container रनटाइम operate करने योग्य विश्वसनीय people को

संबंधित दस्तावेज़​