उपयोगकर्ता, Roles और Permissions

SnapOtter तीन बिल्ट-इन roles, 17 सूक्ष्म permissions, और वैकल्पिक प्रति-टूल एक्सेस नियंत्रण के साथ कस्टम roles का समर्थन प्रदान करता है। यह पेज पूर्ण अधिकृति मॉडल, API key स्कोपिंग, टीम प्रबंधन, और ऑडिट लॉगिंग को कवर करता है।

संबंधित पेज

OIDC / SSO | SAML SSO | SCIM Provisioning | Security & Hardening

उपयोगकर्ता

उपयोगकर्ता बनाना

एडमिन एडमिन पैनल या POST /api/auth/register एंडपॉइंट के माध्यम से उपयोगकर्ता बना सकते हैं। हर उपयोगकर्ता के पास एक उपयोगकर्ता नाम, role, टीम असाइनमेंट, और एक वैकल्पिक ईमेल पता होता है।

डिफ़ॉल्ट एडमिन

पहली बार स्टार्टअप पर SnapOtter एक डिफ़ॉल्ट एडमिन अकाउंट बनाता है। क्रेडेंशियल एनवायरनमेंट वेरिएबल से आते हैं:

Variable	Default	Description
DEFAULT_USERNAME	admin	प्रारंभिक एडमिन अकाउंट के लिए उपयोगकर्ता नाम
DEFAULT_PASSWORD	admin	प्रारंभिक एडमिन अकाउंट के लिए पासवर्ड

डिफ़ॉल्ट एडमिन को पहले लॉगिन पर अपना पासवर्ड बदलना आवश्यक है।

प्रमाणीकरण प्रदाता

उपयोगकर्ता कई विधियों से प्रमाणित हो सकते हैं:

• Local - SnapOtter डेटाबेस में संग्रहीत उपयोगकर्ता नाम और पासवर्ड
• OIDC - कोई भी OpenID Connect प्रदाता (OIDC / SSO देखें)
• SAML - SAML 2.0 पहचान प्रदाता (SAML SSO देखें)
• SCIM - किसी पहचान प्रदाता से स्वचालित प्रोविज़निंग (SCIM Provisioning देखें)

प्रमाणीकरण अक्षम करना

प्रमाणीकरण को पूरी तरह अक्षम करने के लिए AUTH_ENABLED=false सेट करें। इस मोड में सभी अनुरोधों के लिए admin role वाला एक सिंथेटिक अनाम उपयोगकर्ता उपयोग होता है। किसी लॉगिन की आवश्यकता नहीं होती।

WARNING

प्रमाणीकरण अक्षम करने से इंस्टेंस तक पहुँच सकने वाले किसी भी व्यक्ति को पूर्ण एडमिन एक्सेस मिल जाता है। इसका उपयोग केवल भरोसेमंद वातावरण में करें।

बिल्ट-इन roles

SnapOtter में तीन बिल्ट-इन roles शामिल हैं। इन्हें संशोधित या हटाया नहीं जा सकता।

Admin

सभी 17 permissions। इंस्टेंस पर पूर्ण नियंत्रण।

tools:use files:own files:all apikeys:own apikeys:all pipelines:own pipelines:all settings:read settings:write users:manage teams:manage features:manage system:health audit:read compliance:manage webhooks:manage security:manage

Editor

7 permissions। सभी टूल का उपयोग कर सकता है और सभी फ़ाइलें व pipelines प्रबंधित कर सकता है, लेकिन एडमिन फ़ंक्शन तक नहीं पहुँच सकता।

tools:use files:own files:all apikeys:own pipelines:own pipelines:all settings:read

User

5 permissions। टूल का उपयोग कर सकता है और अपने स्वयं के संसाधन प्रबंधित कर सकता है।

tools:use files:own apikeys:own pipelines:own settings:read

Permissions संदर्भ

Permission	Description
tools:use	किसी भी प्रोसेसिंग टूल का उपयोग करना
files:own	अपनी फ़ाइलें देखना और प्रबंधित करना
files:all	सभी उपयोगकर्ताओं की फ़ाइलें देखना और प्रबंधित करना
apikeys:own	अपनी API keys बनाना और प्रबंधित करना
apikeys:all	सभी उपयोगकर्ताओं की API keys देखना
pipelines:own	अपनी pipelines बनाना और प्रबंधित करना
pipelines:all	सभी उपयोगकर्ताओं की pipelines देखना और प्रबंधित करना
settings:read	इंस्टेंस सेटिंग्स देखना
settings:write	इंस्टेंस सेटिंग्स संशोधित करना
users:manage	उपयोगकर्ता अकाउंट बनाना, अपडेट करना, और हटाना
teams:manage	teams बनाना, अपडेट करना, और हटाना
features:manage	AI फ़ीचर बंडल इंस्टॉल और प्रबंधित करना
system:health	health और readiness एंडपॉइंट तक पहुँचना
audit:read	ऑडिट लॉग देखना और roles सूचीबद्ध करना
compliance:manage	GDPR लाइफ़साइकल और अनुपालन फ़ीचर प्रबंधित करना
webhooks:manage	आउटबाउंड webhooks कॉन्फ़िगर करना
security:manage	सुरक्षा सेटिंग्स प्रबंधित करना (IP allowlist, SSO प्रवर्तन)

कस्टम roles

security:manage permission वाले एडमिन एडमिन पैनल या roles API के माध्यम से कस्टम roles बना सकते हैं। roles सूचीबद्ध करने के लिए audit:read आवश्यक है।

कस्टम role बनाना

curl -X POST http://localhost:1349/api/v1/roles \
  -H "Authorization: Bearer si_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "reviewer",
    "description": "Can use tools and view all files",
    "permissions": ["tools:use", "files:own", "files:all", "settings:read"]
  }'

Role नाम 2-30 अक्षरों के होने चाहिए, लोअरकेस अल्फ़ान्यूमेरिक, हाइफ़न और अंडरस्कोर के साथ।

एडमिन-आरक्षित permissions

तीन permissions बिल्ट-इन roles के लिए आरक्षित हैं और कस्टम roles को नहीं सौंपी जा सकतीं:

• compliance:manage
• webhooks:manage
• security:manage

roles API इन permissions को शामिल करने वाले किसी भी अनुरोध को अस्वीकार कर देता है। केवल बिल्ट-इन admin role के पास इन तक पहुँच है।

टूल-स्तरीय permissions

कस्टम roles वैकल्पिक रूप से सीमित कर सकते हैं कि उपयोगकर्ता किन टूल तक पहुँच सकते हैं। दो मोड उपलब्ध हैं:

Mode	Behavior	License requirement
category	मोडैलिटी के अनुसार सीमित करें (image, video, audio, document, file)	कोई नहीं (निःशुल्क)
tool	व्यक्तिगत टूल ID के अनुसार सीमित करें	per_tool_permissions enterprise फ़ीचर आवश्यक है

जब tool मोड सेट होता है लेकिन enterprise फ़ीचर उपलब्ध नहीं होता, तो SnapOtter शालीनता से गिरावट करता है और सभी टूल तक पहुँच की अनुमति देता है।

{
  "name": "image-only",
  "permissions": ["tools:use", "files:own"],
  "toolPermissions": {
    "mode": "category",
    "allowed": ["image"]
  }
}

कस्टम role हटाना

जब कोई कस्टम role हटाया जाता है, तो इसे सौंपे गए सभी उपयोगकर्ता स्वचालित रूप से user role में पुनः-असाइन कर दिए जाते हैं।

Teams

Teams स्टोरेज और रिटेंशन प्रबंधन के लिए उपयोगकर्ताओं को समूहित करती हैं। पहली बार स्टार्टअप पर एक Default टीम बनाई जाती है।

Field	Type	Description
name	string	अद्वितीय टीम नाम (1-50 अक्षर)
storageQuota	number	बाइट्स में प्रति-टीम स्टोरेज सीमा (enterprise के बिना काम करती है)
retentionHours	number	इतने घंटों के बाद आउटपुट स्वतः-हटाएँ (team_retention_overrides आवश्यक है, enterprise)
legalHold	boolean	टीम सदस्यों की फ़ाइलों के स्वचालित विलोपन को रोकें (legal_hold आवश्यक है, enterprise)

INFO

Default टीम को हटाया नहीं जा सकता। जिन teams में अब भी सदस्य हैं उन्हें हटाया नहीं जा सकता। पहले सदस्यों को पुनः-असाइन करें।

API keys

उपयोगकर्ता प्रोग्रामेटिक एक्सेस के लिए API keys जनरेट कर सकते हैं। हर key si_ प्रीफ़िक्स का उपयोग करती है और निर्माण के समय केवल एक बार दिखाई जाती है।

स्कोप्ड permissions

API keys वैकल्पिक रूप से एक permissions ऐरे ले जा सकती हैं। जब सेट किया जाता है, तो किसी अनुरोध के लिए प्रभावी permissions उपयोगकर्ता के role permissions और key की स्कोप्ड permissions का intersection होती हैं। इसका अर्थ है कि एक API key कभी भी उपयोगकर्ता की अपनी permissions से आगे नहीं बढ़ सकती।

curl -X POST http://localhost:1349/api/v1/api-keys \
  -H "Authorization: Bearer si_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "CI pipeline key",
    "permissions": ["tools:use", "files:own"],
    "expiresAt": "2027-01-01T00:00:00Z"
  }'

समाप्ति

Keys एक वैकल्पिक expiresAt टाइमस्टैम्प स्वीकार करती हैं। समाप्त हो चुकी keys प्रमाणीकरण के समय अस्वीकार कर दी जाती हैं।

ऑडिट लॉग

SnapOtter सुरक्षा-संबंधी घटनाओं को audit_log डेटाबेस टेबल में संग्रहीत एक संरचित ऑडिट लॉग में रिकॉर्ड करता है।

ऑडिट लॉग देखना

GET /api/v1/audit-log?page=1&limit=50&action=LOGIN_FAILED&from=2026-01-01T00:00:00Z&to=2026-12-31T23:59:59Z

audit:read permission आवश्यक है। पेजिनेशन (page, limit) और फ़िल्टर (action, ip, from, to) का समर्थन करता है।

टूल ऑपरेशन ऑडिटिंग

WARNING

TOOL_EXECUTED घटनाएँ डिफ़ॉल्ट रूप से लॉग नहीं होतीं। वे दो पथों में से किसी एक के माध्यम से ऑप्ट-इन हैं:

1. auditToolOperations एडमिन सेटिंग को true पर सेट करें।
2. audit_export फ़ीचर वाला एक सक्रिय लाइसेंस रखें (team और enterprise दोनों प्लान पर उपलब्ध)।

इनमें से किसी एक के बिना, व्यक्तिगत टूल निष्पादन ऑडिट लॉग में रिकॉर्ड नहीं होते।

एक्सपोर्ट करना

GET /api/v1/enterprise/audit/export?format=csv&from=2026-01-01T00:00:00Z

audit:read permission और audit_export enterprise फ़ीचर आवश्यक है (team और enterprise दोनों प्लान पर उपलब्ध)। CSV और JSON फ़ॉर्मैट का समर्थन करता है, action, actorId, targetType, targetId, from, और to के अनुसार फ़िल्टर किया जाता है।

छेड़छाड़-प्रतिरोधी हस्ताक्षर

सक्षम होने पर, हर ऑडिट लॉग एंट्री को DATA_ENCRYPTION_KEY से व्युत्पन्न एक HMAC के साथ हस्ताक्षरित किया जाता है। इसके लिए आवश्यक है:

1. अपने एनवायरनमेंट में DATA_ENCRYPTION_KEY सेट करना।
2. tamperResistantAudit एडमिन सेटिंग सक्षम करना।
3. tamper_resistant_audit फ़ीचर वाला एक enterprise लाइसेंस।

रिटेंशन

पुरानी एंट्रियों को स्वचालित रूप से हटाने के लिए AUDIT_RETENTION_DAYS सेट करें। डिफ़ॉल्ट 0 है, जिसका अर्थ है कि एंट्रियाँ अनिश्चित काल तक रखी जाती हैं।

घटना संदर्भ

Event	Category
LOGIN_SUCCESS, LOGIN_FAILED	Authentication
OIDC_LOGIN_SUCCESS, OIDC_LOGIN_FAILED	Authentication
SAML_LOGIN_SUCCESS, SAML_LOGIN_FAILED	Authentication
LOGOUT	Authentication
USER_CREATED, USER_UPDATED, USER_DELETED	User management
PASSWORD_CHANGED, PASSWORD_RESET	User management
MFA_ENROLLED, MFA_DISABLED, MFA_VERIFIED, MFA_VERIFY_FAILED	MFA
MFA_CHALLENGE_ISSUED, MFA_RECOVERY_USED, MFA_RESET	MFA
ROLE_CREATED, ROLE_UPDATED, ROLE_DELETED	Roles
API_KEY_CREATED, API_KEY_DELETED	API keys
SETTINGS_UPDATED, IP_ALLOWLIST_UPDATED	Settings
FILE_UPLOADED, FILE_DELETED	Files
TOOL_EXECUTED	Tools (ऑप्ट-इन)
SCIM_USER_PROVISIONED, SCIM_USER_UPDATED, SCIM_USER_DEPROVISIONED	SCIM
SCIM_GROUP_SYNCED	SCIM
LEGAL_HOLD_APPLIED, LEGAL_HOLD_RELEASED	Compliance
GDPR_EXPORT_INITIATED, GDPR_USER_PURGED, GDPR_TEAM_PURGED	Compliance
CONFIG_EXPORTED, CONFIG_IMPORTED	Configuration

सत्र प्रबंधन

सत्र कुकी-आधारित होते हैं, SESSION_DURATION_HOURS द्वारा नियंत्रित (डिफ़ॉल्ट: 168 घंटे / 7 दिन)।

Role बदलाव सत्रों को अमान्य करते हैं

जब कोई एडमिन किसी उपयोगकर्ता का role बदलता है, तो उस उपयोगकर्ता के सभी सक्रिय सत्र हटा दिए जाते हैं। उपयोगकर्ता को अपनी नई permissions प्राप्त करने के लिए फिर से लॉग इन करना होगा।

सुरक्षा गार्ड

• अंतिम-एडमिन सुरक्षा: अंतिम शेष एडमिन को किसी निचले role में डिमोट नहीं किया जा सकता। यदि आप ऐसा करने की कोशिश करते हैं तो API एक त्रुटि लौटाता है।
• स्व-विलोपन रोकथाम: एडमिन API के माध्यम से अपना खुद का अकाउंट नहीं हटा सकते।