# उपयोगकर्ता, Roles और Permissions {#users-roles-permissions}
SnapOtter तीन बिल्ट-इन roles, 17 सूक्ष्म permissions, और वैकल्पिक प्रति-टूल एक्सेस नियंत्रण के साथ कस्टम roles का समर्थन प्रदान करता है। यह पेज पूर्ण अधिकृति मॉडल, API key स्कोपिंग, टीम प्रबंधन, और ऑडिट लॉगिंग को कवर करता है।
एडमिन एडमिन पैनल या `POST /api/auth/register` एंडपॉइंट के माध्यम से उपयोगकर्ता बना सकते हैं। हर उपयोगकर्ता के पास एक उपयोगकर्ता नाम, role, टीम असाइनमेंट, और एक वैकल्पिक ईमेल पता होता है।
### डिफ़ॉल्ट एडमिन {#default-admin}
पहली बार स्टार्टअप पर SnapOtter एक डिफ़ॉल्ट एडमिन अकाउंट बनाता है। क्रेडेंशियल एनवायरनमेंट वेरिएबल से आते हैं:
| Variable | Default | Description |
|---|---|---|
| `DEFAULT_USERNAME` | `admin` | प्रारंभिक एडमिन अकाउंट के लिए उपयोगकर्ता नाम |
| `DEFAULT_PASSWORD` | `admin` | प्रारंभिक एडमिन अकाउंट के लिए पासवर्ड |
डिफ़ॉल्ट एडमिन को पहले लॉगिन पर अपना पासवर्ड बदलना आवश्यक है।
- **SCIM** - किसी पहचान प्रदाता से स्वचालित प्रोविज़निंग ([SCIM Provisioning](/hi/guide/scim) देखें)
### प्रमाणीकरण अक्षम करना {#disabling-authentication}
प्रमाणीकरण को पूरी तरह अक्षम करने के लिए `AUTH_ENABLED=false` सेट करें। इस मोड में सभी अनुरोधों के लिए `admin` role वाला एक सिंथेटिक अनाम उपयोगकर्ता उपयोग होता है। किसी लॉगिन की आवश्यकता नहीं होती।
::: warning
प्रमाणीकरण अक्षम करने से इंस्टेंस तक पहुँच सकने वाले किसी भी व्यक्ति को पूर्ण एडमिन एक्सेस मिल जाता है। इसका उपयोग केवल भरोसेमंद वातावरण में करें।
:::
## बिल्ट-इन roles {#built-in-roles}
SnapOtter में तीन बिल्ट-इन roles शामिल हैं। इन्हें संशोधित या हटाया नहीं जा सकता।
| `webhooks:manage` | आउटबाउंड webhooks कॉन्फ़िगर करना |
| `security:manage` | सुरक्षा सेटिंग्स प्रबंधित करना (IP allowlist, SSO प्रवर्तन) |
## कस्टम roles {#custom-roles}
`security:manage` permission वाले एडमिन एडमिन पैनल या roles API के माध्यम से कस्टम roles बना सकते हैं। roles सूचीबद्ध करने के लिए `audit:read` आवश्यक है।
### कस्टम role बनाना {#creating-a-custom-role}
```bash
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",
सभी 17 अनुमतियाँ कस्टम भूमिकाओं के माध्यम से सौंपी जा सकती हैं, लेकिन एक प्रशासनिक अनुमति उस भूमिका को अंतर्निहित `admin` भूमिका के बराबर नहीं बनाती है। `users:manage` द्वारा अधिकृत उपयोगकर्ता उत्परिवर्तन, `compliance:manage` द्वारा अधिकृत विनाशकारी संचालन, और `security:manage` द्वारा अधिकृत कस्टम-भूमिका प्रबंधन अभिनेता के वर्तमान अधिकार से बंधे हैं:
- अंतर्निहित भूमिकाएँ `admin` > `editor` > `user` का अनुसरण करती हैं; कस्टम भूमिकाएँ अंतर्निहित भूमिकाओं के नीचे हैं।
- लक्ष्य की अनुमतियाँ अभिनेता की **प्रभावी** अनुमतियों में समाहित होनी चाहिए। इसलिए एक स्कोप्ड एपीआई कुंजी अपने दायरे से छोड़ी गई अनुमतियों का उपयोग नहीं कर सकती है।
- एक लक्ष्य भूमिका की टूल एक्सेस अभिनेता की अपनी टूल एक्सेस में समाहित होनी चाहिए।
- एक अक्षम खाते की जाँच उसकी मूल भूमिका के विरुद्ध की जाती है जब वह भूमिका `disabled:<original-role>` के रूप में दर्ज की जाती है।
- किसी कस्टम भूमिका को हटाने के लिए अंतर्निहित `user` फ़ॉलबैक असाइन करने के लिए प्राधिकरण की भी आवश्यकता होती है; अक्षम सदस्य `disabled:user` के रूप में अक्षम रहते हैं।
वैश्विक क्रेडेंशियल और कॉन्फ़िगरेशन सख्त हैं: SCIM टोकन जारी करने या रद्द करने और इंस्टेंस कॉन्फ़िगरेशन आयात करने के लिए पूर्ण प्रभावी व्यवस्थापक प्राधिकरण के साथ अंतर्निहित `admin` भूमिका की आवश्यकता होती है।
कस्टम roles वैकल्पिक रूप से सीमित कर सकते हैं कि उपयोगकर्ता किन टूल तक पहुँच सकते हैं। दो मोड उपलब्ध हैं:
| Mode | Behavior | License requirement |
|---|---|---|
| `category` | मोडैलिटी के अनुसार सीमित करें (image, video, audio, document, file) | कोई नहीं (निःशुल्क) |
| `tool` | व्यक्तिगत टूल ID के अनुसार सीमित करें | `per_tool_permissions` enterprise फ़ीचर आवश्यक है |
जब `tool` मोड सेट होता है लेकिन enterprise फ़ीचर उपलब्ध नहीं होता, तो SnapOtter शालीनता से गिरावट करता है और सभी टूल तक पहुँच की अनुमति देता है।
```json
{
"name":"image-only",
"permissions":["tools:use","files:own"],
"toolPermissions":{
"mode":"category",
"allowed":["image"]
}
}
```
### कस्टम role हटाना {#deleting-a-custom-role}
जब कोई कस्टम role हटाया जाता है, तो इसे सौंपे गए सभी उपयोगकर्ता स्वचालित रूप से `user` role में पुनः-असाइन कर दिए जाते हैं।
## Teams {#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}
उपयोगकर्ता प्रोग्रामेटिक एक्सेस के लिए API keys जनरेट कर सकते हैं। हर key `si_` प्रीफ़िक्स का उपयोग करती है और निर्माण के समय केवल एक बार दिखाई जाती है।
### स्कोप्ड permissions {#scoped-permissions}
API keys वैकल्पिक रूप से एक `permissions` ऐरे ले जा सकती हैं। जब सेट किया जाता है, तो किसी अनुरोध के लिए प्रभावी permissions उपयोगकर्ता के role permissions और key की स्कोप्ड permissions का **intersection** होती हैं। इसका अर्थ है कि एक API key कभी भी उपयोगकर्ता की अपनी permissions से आगे नहीं बढ़ सकती।
```bash
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"
}'
```
### समाप्ति {#expiration}
Keys एक वैकल्पिक `expiresAt` टाइमस्टैम्प स्वीकार करती हैं। समाप्त हो चुकी keys प्रमाणीकरण के समय अस्वीकार कर दी जाती हैं।
## ऑडिट लॉग {#audit-log}
SnapOtter सुरक्षा-संबंधी घटनाओं को `audit_log` डेटाबेस टेबल में संग्रहीत एक संरचित ऑडिट लॉग में रिकॉर्ड करता है।
### ऑडिट लॉग देखना {#viewing-the-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`) का समर्थन करता है।
### टूल ऑपरेशन ऑडिटिंग {#tool-operation-auditing}
::: warning
`TOOL_EXECUTED` घटनाएँ डिफ़ॉल्ट रूप से लॉग **नहीं** होतीं। वे दो पथों में से किसी एक के माध्यम से ऑप्ट-इन हैं:
1.`auditToolOperations` एडमिन सेटिंग को `true` पर सेट करें।
2.`audit_export` फ़ीचर वाला एक सक्रिय लाइसेंस रखें (team और enterprise दोनों प्लान पर उपलब्ध)।
इनमें से किसी एक के बिना, व्यक्तिगत टूल निष्पादन ऑडिट लॉग में रिकॉर्ड नहीं होते।
:::
### एक्सपोर्ट करना {#exporting}
```
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 लाइसेंस।
### रिटेंशन {#retention}
पुरानी एंट्रियों को स्वचालित रूप से हटाने के लिए `AUDIT_RETENTION_DAYS` सेट करें। डिफ़ॉल्ट `0` है, जिसका अर्थ है कि एंट्रियाँ अनिश्चित काल तक रखी जाती हैं।
सत्र कुकी-आधारित होते हैं, `SESSION_DURATION_HOURS` द्वारा नियंत्रित (डिफ़ॉल्ट: 168 घंटे / 7 दिन)।
### Role बदलाव सत्रों को अमान्य करते हैं {#role-changes-invalidate-sessions}
जब कोई एडमिन किसी उपयोगकर्ता का role बदलता है, तो उस उपयोगकर्ता के सभी सक्रिय सत्र हटा दिए जाते हैं। उपयोगकर्ता को अपनी नई permissions प्राप्त करने के लिए फिर से लॉग इन करना होगा।
### सुरक्षा गार्ड {#safety-guards}
- **अंतिम-एडमिन सुरक्षा**: अंतिम शेष एडमिन को किसी निचले role में डिमोट नहीं किया जा सकता। यदि आप ऐसा करने की कोशिश करते हैं तो API एक त्रुटि लौटाता है।
- **स्व-विलोपन रोकथाम**: एडमिन API के माध्यम से अपना खुद का अकाउंट नहीं हटा सकते।
