प्रमाणीकरण

/api/v1 पर हर कॉल के लिए क्रेडेंशियल चाहिए, सिवाय सार्वजनिक हेल्थ चेक, साइन-इन विकल्प, साइन-इन और पंजीकरण के। यह पृष्ठ क्रेडेंशियल के प्रकार, हर एक को कैसे पाना और भेजना है, और API संदर्भ में एक्सेस नियमों का अर्थ बताता है। एक्सेस प्रबंधित करने वाले लोगों के नियमों के लिए खाते और एक्सेस देखें।

एक नज़र में क्रेडेंशियल

क्रेडेंशियल	कैसा दिखता है	यह कैसे मिलता है	जीवनकाल	किसके लिए इस्तेमाल करें
कंसोल सत्र	`dps_…`	नाम और पासवर्ड से साइन इन करना	12 घंटे	कंसोल में कोई व्यक्ति, या साइन इन करने वाली स्क्रिप्ट
व्यक्तिगत एक्सेस टोकन	`pat_…`	सत्र से इसे बनाना	डिफ़ॉल्ट रूप से 90 दिन, अधिकतम 365	एक व्यक्ति की स्क्रिप्ट और टूल
सेवा कुंजी	`arkvory_…`	सेवा खाते के लिए जारी करना, फिर उसे सक्रिय करना	डिफ़ॉल्ट रूप से 90 दिन, अधिकतम 365	CI/CD, डिप्लॉयमेंट एजेंट, अन्य सिस्टम
पुनर्प्राप्ति कुंजी	64 हेक्साडेसिमल अंक	इंस्टॉलर इसे `config/bootstrap-token.txt` में लिखता है	समाप्त नहीं होती	स्वामी बनाना, सेवा खातों का प्रबंधन, एक्सेस पुनर्प्राप्त करना
डाउनलोड लिंक	`dtl_…`	एक आर्टिफ़ैक्ट के लिए इसे बनाना	60 सेकंड से 24 घंटे	बिना कुंजी वाले किसी व्यक्ति को एक आर्टिफ़ैक्ट देना

ऑटोमेशन के लिए सेवा कुंजी और किसी व्यक्ति के टूल के लिए व्यक्तिगत एक्सेस टोकन इस्तेमाल करें। रोज़मर्रा के काम के लिए पुनर्प्राप्ति कुंजी का उपयोग न करें।

हेडर प्रारूप

/api/v1 एक हेडर में क्रेडेंशियल स्वीकार करता है:

http

Authorization: Bearer <credential>

क्रेडेंशियल 32 से 512 अक्षरों का होता है। कुछ और होने पर तुरंत credential_invalid मिलता है।
कंटेनर रजिस्ट्री (/v2), Git LFS (/lfs) और npm रजिस्ट्री (/npm) HTTP Basic भी स्वीकार करते हैं, क्योंकि docker login, git और npm क्रेडेंशियल उसी तरह भेजते हैं। उपयोगकर्ता नाम की जाँच नहीं होती; पासवर्ड ही क्रेडेंशियल है। क्लाइंट और प्रोटोकॉल देखें।
डाउनलोड लिंक क्वेरी स्ट्रिंग में ?token=dtl_… के रूप में जाता है, और केवल एक आर्टिफ़ैक्ट के कंटेंट मार्ग पर काम करता है। डाउनलोड लिंक देखें। Authorization हेडर हमेशा क्वेरी पर भारी पड़ता है।
मान्य क्रेडेंशियल के बिना अनुरोध को WWW-Authenticate: Bearer और एक कारण के साथ 401 मिलता है: credential_missing, credential_invalid, session_expired या token_expired। समाप्त क्रेडेंशियल के सटीक सीक्रेट का धारक ही जानता है कि वह समाप्त हो गया।
कोई कुकी नहीं। Arkvory न सेट करता है न पढ़ता है, इसलिए ब्राउज़र स्वयं कभी क्रेडेंशियल नहीं जोड़ता और बचाव के लिए कोई क्रॉस-साइट अनुरोध जालसाज़ी नहीं होती। स्क्रिप्ट हर कॉल पर हेडर भेजती है। कंसोल अपना सत्र टोकन ब्राउज़र टैब की मेमोरी में रखता है और टैब बंद करने पर उसे भूल जाता है।
अन्य origins। Arkvory के समान पते पर मौजूद पृष्ठ को कुछ नहीं चाहिए। किसी दूसरे पते पर मौजूद पृष्ठ मान्य क्रेडेंशियल के साथ भी 403 और कारण origin_not_allowed के साथ अस्वीकार कर दिया जाता है, जब तक व्यवस्थापक उसका origin ARKVORY_CORS_ORIGINS में सूचीबद्ध न करे। HTTPS इस्तेमाल करें: सादे HTTP में क्रेडेंशियल नेटवर्क पर पढ़ा जा सकता है। HTTPS देखें।

जाँचें कि क्रेडेंशियल क्या है और क्या कर सकता है:

bash

curl -fsS -H "Authorization: Bearer $ARKVORY_KEY" "$ARKVORY_URL/api/v1/auth/me"
curl -fsS -H "Authorization: Bearer $ARKVORY_KEY" "$ARKVORY_URL/api/v1/auth/permissions"

कंसोल साइन-इन सत्र

कोई व्यक्ति नाम और पासवर्ड से साइन इन करता है और सत्र पाता है। कंसोल यह आपके लिए करता है; स्क्रिप्ट भी यही कर सकती है।

नाम और पासवर्ड को एक निजी फ़ाइल login.json में रखें, ताकि वे कभी कमांड लाइन या प्रोसेस सूची में न दिखें:
json
```
{ "name": "alice", "password": "a long password of 12 to 128 characters" }
```

login कॉल करें:

bash

curl -fsS -X POST "$ARKVORY_URL/api/v1/auth/login" \
  -H "Content-Type: application/json" -d @login.json

उत्तर में सत्र टोकन और उसका समाप्ति समय होता है:

json

{
  "token": "dps_…",
  "expiresAt": "2026-10-05T21:30:00.000Z",
  "account": { "id": "…", "name": "alice", "administrator": false, "enabled": true }
}

टोकन को Authorization: Bearer dps_… के रूप में भेजें।

सत्र के नियम:

यह 12 घंटे रहता है और बढ़ता नहीं। उसके बाद हर कॉल session_expired कारण के साथ 401 लौटाती है। फिर से साइन इन करें।
एक खाते में अधिकतम 32 सत्र होते हैं। नया साइन-इन उससे अधिक पुराने वाले समाप्त कर देता है।
POST /api/v1/auth/logout सत्र समाप्त करता है। अपना पासवर्ड बदलने पर, या व्यवस्थापक द्वारा उसे रीसेट करने पर, खाते के सभी सत्र और सभी व्यक्तिगत टोकन समाप्त हो जाते हैं। खाता अक्षम करने पर वे रुक जाते हैं।
सत्र खाते का पूरा अधिकार ले जाता है, व्यवस्थापक फ़्लैग सहित। केवल सत्र ही व्यक्तिगत टोकन बना और निरस्त कर सकता है और खाते का अपना पासवर्ड बदल सकता है।
नामों की तुलना बिना केस भेद के होती है। गलत नाम, गलत पासवर्ड और अक्षम खाता एक ही 401 और कारण invalid_credentials देते हैं।
रीड गेटवे किसी को साइन इन नहीं कराता; राइटर इस्तेमाल करें।

स्वयं-पंजीकरण

GET /api/v1/auth/options सार्वजनिक है और बताता है कि लोग अपने खाते बना सकते हैं या नहीं। स्वयं-पंजीकरण बंद रहता है, जब तक व्यवस्थापक ARKVORY_ALLOW_REGISTRATION=true सेट न करे; तब साइन-इन जैसी ही बॉडी वाला POST /api/v1/auth/register एक साधारण खाता (व्यवस्थापक नहीं, किसी भी रिपॉज़िटरी तक पहुँच के बिना) बनाता है और 201 के साथ सत्र लौटाता है। अन्यथा वह registration_disabled कारण के साथ 403 उत्तर देता है। स्वयं-पंजीकरण 900 खातों पर रुक जाता है, ताकि व्यवस्थापक अभी भी 1,000 की सीमा तक खाते बना सकें।

व्यक्तिगत एक्सेस टोकन

व्यक्तिगत एक्सेस टोकन किसी स्क्रिप्ट को आपके पासवर्ड के बिना आपके रूप में काम करने देता है। केवल साइन-इन किया हुआ सत्र ही इसे बना सकता है।

bash

curl -fsS -X POST "$ARKVORY_URL/api/v1/auth/tokens" \
  -H "Authorization: Bearer $SESSION" -H "Content-Type: application/json" \
  -d '{"name":"laptop-cli","scope":"read-write","expiresAt":"2026-12-31T00:00:00Z"}'

कंसोल में रिपॉज़िटरी कनेक्शन कार्ड में व्यक्तिगत एक्सेस टोकन खोलें, टोकन का नाम दर्ज करें, एक्सेस और समाप्ति अवधि चुनें, और टोकन बनाएँ चुनें।

फ़ील्ड	नियम
`name`	1 से 64 अक्षर।
`scope`	`read` या `read-write`। छोड़ने पर API `read-write` इस्तेमाल करता है; कंसोल पहले केवल पढ़ना देता है।
`expiresAt`	भविष्य का RFC 3339 समय, अधिकतम 365 दिन दूर। डिफ़ॉल्ट 90 दिन है। बिना अंत वाले टोकन नहीं होते।

201 उत्तर में टोकन एक बार, token के रूप में होता है। उसे तब सहेजें: सर्वर केवल हैश रखता है, और सूची छोटा प्रीफ़िक्स दिखाती है। फिर:

टोकन को अपने खाते की रिपॉज़िटरी पहुँच मिलती है, और कुछ नहीं। उसमें कभी व्यवस्थापक फ़्लैग नहीं होता, इसलिए वह खाते, समूह, अपडेट या बैकअप प्रबंधित नहीं कर सकता।
read टोकन केवल पढ़ सकता है। logout को छोड़कर कुछ बदलने वाला कोई भी अनुरोध, ऑपरेशन चलने से पहले, 403 और कारण read_only_token के साथ अस्वीकार कर दिया जाता है।
टोकन टोकन नहीं बना सकता और पासवर्ड नहीं बदल सकता; उनके लिए सत्र चाहिए।
एक खाते में अधिकतम 50 सक्रिय टोकन होते हैं। GET /api/v1/auth/tokens उन्हें उनके प्रीफ़िक्स, scope, अंत और अंतिम उपयोग के साथ सूचीबद्ध करता है। DELETE /api/v1/auth/tokens/{id} एक को तुरंत निरस्त करता है (कंसोल में टोकन निरस्त करें)। व्यवस्थापक किसी भी खाते के टोकन सूचीबद्ध और निरस्त कर सकता है।
समाप्त टोकन token_expired कारण के साथ 401 लौटाता है।

सेवा खाते और कुंजियाँ

सेवा खाता किसी टूल, जैसे बिल्ड एजेंट, की पहचान होती है। इसकी एक नीति होती है: बाइंडिंग की सूची, जिनमें से हर एक एक रिपॉज़िटरी और वहाँ अनुमत सटीक कार्रवाइयाँ बताता है (रिपॉज़िटरी कार्रवाइयाँ देखें)। एक नीति में अधिकतम 64 बाइंडिंग होती हैं। खाता उन अपलोड और जॉब का स्वामी होता है जो उसकी कुंजियाँ शुरू करती हैं, इसलिए कुंजी रोटेट करने से कुछ नहीं खोता। एक सर्वर में अधिकतम 1,000 सेवा खाते होते हैं।

केवल पुनर्प्राप्ति कुंजी सेवा खाता बनाती है। वह, या प्रत्यायोजन वाला ऑपरेटर, मौजूद खातों को बदलता है। कंसोल में सेवा एक्सेस इस्तेमाल करें: सेवा खाता बनाएँ, फिर रिपॉज़िटरी अनुमतियाँ सेट करें। पढ़ने का प्रीसेट सात read कार्रवाइयाँ भरता है, और प्रकाशन का प्रीसेट पैकेज अपलोड और पंजीकृत करने के लिए ज़रूरी कार्रवाइयाँ जोड़ता है।

bash

curl -fsS -X POST "$ARKVORY_URL/api/v1/service-accounts" \
  -H "Authorization: Bearer $RECOVERY_KEY" -H "Content-Type: application/json" \
  -d '{"name":"ci-release","bindings":[{"resource":{"kind":"repository","id":"releases"},
       "actions":["repository.read","artifact.read","upload.create","upload.read","upload.write",
                  "upload.complete","upload.cancel","job.read","package.publish"]}]}'

नाम 3 से 64 अक्षर, अंक, _, . और - इस्तेमाल करते हैं। नीति बदलने के लिए, जो expectedRevision पढ़ा था उसके साथ PUT /api/v1/service-accounts/{id}/policy भेजें (compare-and-swap)। खाता बंद करने के लिए, {"expectedRevision": n, "enabled": false} के साथ PATCH /api/v1/service-accounts/{id} भेजें; जब तक आप उसे फिर से चालू न करें, उसकी सभी कुंजियाँ काम करना बंद कर देती हैं।

सेवा कुंजियाँ

कुंजी वह सीक्रेट है जिससे सेवा खाता साइन इन करता है। यह arkvory_<uuid>.<secret> जैसी दिखती है। कुंजी तीन अवस्थाओं से गुज़रती है: pending, active और revoked।

जारी करें। Idempotency-Key, name, कुंजी द्वारा इस्तेमाल होने योग्य bindings और, यदि चाहें, expiresAt (UTC, 365 दिन के भीतर; डिफ़ॉल्ट 90 है) के साथ POST /api/v1/service-accounts/{id}/keys भेजें। कुंजी की बाइंडिंग खाते की नीति के भीतर होनी चाहिए। उत्तर 201 में कुंजी का मेटाडेटा और, केवल इस बार, उसका secret होता है। उसी आइडेम्पोटेंसी कुंजी के साथ दोहराव मेटाडेटा के साथ 200 लौटाता है, बिना सीक्रेट।
सक्रिय करें। नई कुंजी pending होती है और एक कॉल POST /api/v1/auth/activate-key को छोड़कर अनुपयोगी रहती है, जिसमें नया सीक्रेट क्रेडेंशियल के रूप में होता है। उत्तर 204 होता है। यह 15 मिनट के भीतर करें; उसके बाद कुंजी बिना उपयोग के समाप्त हो जाती है। कंसोल में सीक्रेट कॉपी करें, मैंने सीक्रेट सहेज लिया है चुनें और फिर कुंजी सक्रिय करें। दोबारा सक्रिय करना हानिरहित है।
उपयोग। कुंजी अपने expiresAt तक, या निरस्त होने या उसका खाता अक्षम होने तक काम करती है।

bash

curl -fsS -X POST "$ARKVORY_URL/api/v1/service-accounts/$ACCOUNT/keys" \
  -H "Authorization: Bearer $RECOVERY_KEY" -H "Idempotency-Key: ci-release-2026-10" \
  -H "Content-Type: application/json" \
  -d '{"name":"ci-release-2026-10","bindings":[{"resource":{"kind":"repository","id":"releases"},
       "actions":["upload.create","upload.read","upload.write","upload.complete","job.read"]}]}'
curl -fsS -X POST "$ARKVORY_URL/api/v1/auth/activate-key" -H "Authorization: Bearer $NEW_SECRET"

सीमाएँ: एक खाते में एक समय पर अधिकतम 3 सक्रिय कुंजियाँ और 2 pending कुंजियाँ होती हैं (507, कारण key_limit)।

रोटेट करें। POST /api/v1/api-keys/{id}/rotate उसी खाते के लिए नई pending कुंजी जारी करता है, जारी करने जैसी ही बॉडी और एक Idempotency-Key के साथ। उसकी बाइंडिंग पुरानी कुंजी की बाइंडिंग के भीतर होनी चाहिए। जब आप नई कुंजी सक्रिय करते हैं, तो पुरानी कुंजी का अंत उस समय से अधिकतम 24 घंटे तक काट दिया जाता है। अपने टूल को नई कुंजी पर ले जाएँ, फिर पुरानी को निरस्त करें। कंसोल में: रोटेट करें।

निरस्त करें। POST /api/v1/api-keys/{id}/revoke कुंजी को हमेशा के लिए समाप्त करता है; इसे दोहराना हानिरहित है। कंसोल में: निरस्त करें। कुंजी निरस्त करना उस ट्रांसफ़र को नहीं रोकता जो पहले ही शुरू हो चुका है। pending कुंजी का सीक्रेट खो गया? उसे निरस्त करें और नई आइडेम्पोटेंसी कुंजी के साथ दूसरी जारी करें।

प्रत्यायोजन

पुनर्प्राप्ति कुंजी प्रबंधन का कुछ हिस्सा किसी ऑपरेटर को सौंप सकती है: ऐसा सेवा खाता जिसकी कुंजी अन्य सेवा खातों का प्रबंधन कर सकती है। प्रत्यायोजन ऑपरेटर की कुंजी, लक्ष्य खाता, उस पर ऑपरेटर द्वारा इस्तेमाल होने योग्य प्रबंधन कार्रवाइयाँ, और एक सीमा बताता है, यानी वे रिपॉज़िटरी कार्रवाइयाँ जो वह दे सकता है। सात प्रबंधन कार्रवाइयाँ हैं:

कार्रवाई	क्या अनुमति देती है
`service-account.read`	सूचियों में खाता देखना और उसका कार्ड पढ़ना।
`service-account.manage`	खाता चालू या बंद करना।
`policy.read`	खाते की नीति पढ़ना।
`policy.manage`	खाते की नीति बदलना।
`credential.read`	खाते की कुंजियाँ सूचीबद्ध करना और कुंजी पढ़ना।
`credential.manage`	कुंजियाँ जारी करना, रोटेट करना और निरस्त करना।
`service-audit.read`	खाते की कुंजी इतिहास पढ़ना।

नियम: ऑपरेटर की कुंजी वह होनी चाहिए जिसे पुनर्प्राप्ति कुंजी ने जारी किया हो; ऑपरेटर कभी अपना खाता प्रबंधित नहीं करता; वह अपनी सीमा से बाहर या खाते की नीति से परे कुछ नहीं दे सकता; उसकी जारी की गई कुंजी अपनी कुंजी से अधिक नहीं जी सकती; और प्रत्यायोजन समाप्त करने से पहले से सक्रिय किए गए कुंजी निरस्त नहीं होते। केवल पुनर्प्राप्ति कुंजी खाते बनाती है और प्रत्यायोजन सेट करती है (PUT और DELETE /api/v1/api-keys/{id}/delegations/{accountId})। एक ऑपरेटर कुंजी में 64 तक प्रत्यायोजन हो सकते हैं। कंसोल में प्रत्यायोजित प्रशासन इस्तेमाल करें। अपने प्रत्यायोजन से बाहर कुछ चाहने वाले ऑपरेटर को ऐसे खाते के लिए 404 मिलता है जिसे वह प्रबंधित नहीं करता, या 403।

पुनर्प्राप्ति कुंजी

इंस्टॉलर पुनर्प्राप्ति कुंजी एक बार बनाता है और उसे इंस्टॉलेशन रूट में config/bootstrap-token.txt में लिखता है। केवल Windows पर Administrators समूह, या Linux पर root, फ़ाइल पढ़ सकता है। उसका हैश सर्वर की कुंजी फ़ाइल (ARKVORY_KEYS_FILE) में bootstrap-owner नाम के अंतर्गत होता है। इंस्टॉलर config/health-token.txt भी बनाता है, जो बिना किसी रिपॉज़िटरी अधिकार वाली दूसरी कुंजी है, जो प्रमाणित हेल्थ चेक और मेट्रिक्स कॉल कर सकती है।

पुनर्प्राप्ति कुंजी क्या कर सकती है:

पहला खाता और उसके बाद हर खाता बनाना, पासवर्ड रीसेट करना, खाते अक्षम करना, और समूह तथा उनके रिपॉज़िटरी अनुदान प्रबंधित करना।
सुरक्षा ऑडिट पढ़ना और किसी भी खाते के व्यक्तिगत टोकन निरस्त करना।
सेवा खाते बनाना, उनकी नीतियाँ सेट करना, उनकी कुंजियाँ जारी और निरस्त करना, और प्रत्यायोजन सेट करना।
बैकअप और अपडेट पढ़ना और अनुरोध करना, और फ़ीडबैक के लिए सर्वर लॉग डाउनलोड करना।
पढ़ना और लिखना एक्सेस वाले समूह के सदस्य की तरह रिपॉज़िटरी releases पढ़ना और लिखना।

यह क्या नहीं कर सकती: releases के अलावा किसी रिपॉज़िटरी तक इसकी पहुँच नहीं है, आर्टिफ़ैक्ट हटा नहीं सकती या स्टोरेज नीतियाँ प्रबंधित नहीं कर सकती (वे कार्रवाइयाँ केवल सेवा कुंजियों के लिए हैं), और यह सत्र नहीं है, इसलिए व्यक्तिगत टोकन नहीं बना सकती या पासवर्ड नहीं बदल सकती। इसे सर्वर पर ही रखें। इंस्टॉलेशन टूल इसे वहीं पढ़ते हैं। इसे CI में न रखें, और इसे टूल में पेस्ट न करें; इसके बजाय सेवा कुंजी बनाएँ। इसे बदलने के लिए, कॉन्फ़िगरेशन देखें।

कंसोल का पहला स्वामी बनाएँ फ़ॉर्म (शुरुआत के अंतर्गत) पहला स्वामी बनाने के लिए पुनर्प्राप्ति कुंजी इस्तेमाल करता है। यह केवल तब काम करता है जब कोई खाता मौजूद न हो। सत्र के बिना किसी मौजूद खाते का पासवर्ड रीसेट करने के लिए, GET /api/v1/users से उसकी ID खोजें, नया पासवर्ड (12 से 128 अक्षर) एक निजी फ़ाइल में रखें और उसे पुनर्प्राप्ति कुंजी के साथ भेजें। रीसेट उस खाते के सभी सत्र और टोकन समाप्त कर देता है।

bash

echo '{"password": "a new password of 12 to 128 characters"}' > reset.json
curl -fsS -X PATCH "$ARKVORY_URL/api/v1/users/$USER_ID" \
  -H "Authorization: Bearer $RECOVERY_KEY" -H "Content-Type: application/json" -d @reset.json
rm reset.json

अन्य फ़ाइल कुंजियाँ व्यवस्थापक द्वारा कुंजी फ़ाइल में जोड़ी जा सकती हैं। हर प्रविष्टि में id, सीक्रेट का sha256, मिलने वाली repositories और permissions (read और write), और वैकल्पिक रूप से administrator और serviceAdministrator फ़्लैग होते हैं। फ़ाइल स्टार्टअप पर पढ़ी जाती है, इसलिए बदलाव के बाद API और वर्कर रीस्टार्ट करें।

डाउनलोड लिंक

POST /api/v1/repositories/{repository}/artifacts/{id}/links एक आर्टिफ़ैक्ट के लिए token (dtl_…) और url लौटाता है। ttlSeconds से जीवनकाल माँगें: 60 से 86,400, और डिफ़ॉल्ट रूप से 3,600। कॉलर को content.read चाहिए।

लिंक केवल /api/v1/repositories/{repository}/artifacts/{id}/content?token=… के GET या HEAD के रूप में काम करता है, उस रिपॉज़िटरी में उस आर्टिफ़ैक्ट के लिए, और केवल पढ़ने के लिए। यह एक सीक्रेट है। सर्वर इसे समाप्त होने से पहले निरस्त नहीं कर सकता, और यह लॉग में नहीं दिखता। जितना छोटा जीवन चाहिए उतने छोटे लिंक बनाएँ।

एक्सेस नियम का अर्थ

संदर्भ में हर ऑपरेशन की एक Access पंक्ति होती है। नियमों के प्रकार ये हैं:

संदर्भ में नियम	यह क्या माँगता है
कोई भी, बिना कुंजी	कुछ नहीं। Liveness, readiness स्थिति, साइन-इन विकल्प, साइन-इन और पंजीकरण।
कोई भी मान्य कुंजी या सत्र	कोई भी मान्य क्रेडेंशियल। उदाहरण: क्षमताएँ, ऑपरेशन सूची, आपकी अपनी पहचान, readiness विवरण और मेट्रिक्स।
साइन-इन किया खाता सत्र (कुंजी नहीं)	किसी व्यक्ति का सत्र। व्यक्तिगत टोकन और कुंजियाँ अस्वीकार कर दी जाती हैं (`session_required`)। उदाहरण: अपने टोकन बनाना और निरस्त करना, अपना पासवर्ड बदलना।
व्यवस्थापक	व्यवस्थापक खाते का सत्र, या व्यवस्थापक फ़्लैग वाली फ़ाइल कुंजी, जैसे पुनर्प्राप्ति कुंजी। व्यक्तिगत टोकन और सेवा कुंजियाँ अस्वीकार कर दी जाती हैं (`administrator_required`)। उदाहरण: खाते, समूह, सुरक्षा ऑडिट, अपडेट।
Bootstrap कुंजी (इंस्टॉलेशन पुनर्प्राप्ति कुंजी)	सेवा-प्रबंधन फ़्लैग वाली फ़ाइल कुंजी। पुनर्प्राप्ति कुंजी में यह होता है। उदाहरण: सेवा खाते बनाना और प्रत्यायोजन सेट करना।
Bootstrap कुंजी, या कुंजी स्वयं	पुनर्प्राप्ति कुंजी, या वह कुंजी जिसके प्रत्यायोजन सूचीबद्ध हैं।
जारी की गई कुंजी, सक्रियण से पहले या बाद	एकमात्र ऑपरेशन जो pending कुंजी स्वीकार करता है: सक्रियण।
जो रिपॉज़िटरी कॉलर देख सकता है	उस रिपॉज़िटरी पर कार्रवाई `repository.read`, या सत्र/फ़ाइल कुंजी के लिए उस तक कोई भी पहुँच। जिस रिपॉज़िटरी को कॉलर नहीं देख सकता वह सूचियों से बाहर रहती है और `404` उत्तर देती है।
सिस्टम अनुमति `backup.read` या `backup.manage`	व्यवस्थापक सत्रों और व्यवस्थापक फ़्लैग वाली फ़ाइल कुंजियों के पास होती है। सेवा कुंजियों और व्यक्तिगत टोकन के पास कभी नहीं होती। `backup.manage` में `backup.read` शामिल है।
सेवा प्रबंधन अनुमति	लक्ष्य खाते पर सात प्रबंधन कार्रवाइयों में से एक, किसी प्रत्यायोजन से, या पुनर्प्राप्ति कुंजी।
रिपॉज़िटरी अनुमति	पथ में नामित रिपॉज़िटरी पर सूचीबद्ध रिपॉज़िटरी कार्रवाइयों में से सभी। कई एक्सेस नियम शर्तें जोड़ते हैं: अपलोड, जॉब या संदर्भ कॉलर का होना चाहिए।

रिपॉज़िटरी पंक्ति का दूसरा भाग, जैसे "file keys: read, write", वह मोटा अनुदान है जिसकी लोगों और फ़ाइल कुंजियों को सटीक कार्रवाइयों के बजाय ज़रूरत होती है। समूह अनुदान देखें।

एक्सेस नियम के अलावा, सर्वर मिरर वाली रिपॉज़िटरी में बदलाव भी अस्वीकार करता है (409, mirror_read_only), और रीड गेटवे हर बदलाव अस्वीकार करता है (405, read_only)।

रिपॉज़िटरी अनुमतियाँ

समूह अनुदान

लोगों को समूहों के माध्यम से रिपॉज़िटरी एक्सेस मिलता है। व्यवस्थापक किसी समूह को किसी रिपॉज़िटरी पर read या write अनुदान देता है ("Read and write" के रूप में दिखाया जाता है), और समूह में खाते जोड़ता है। कंसोल में: उपयोगकर्ता और एक्सेस, फिर रिपॉज़िटरी एक्सेस प्रबंधित करें और एक्सेस सहेजें। API कॉल PUT /api/v1/access-groups/{id}/grants/{repository} हैं, {"access": "read"} या {"access": "write"} के साथ, और PUT /api/v1/access-groups/{id}/members/{userId}। अधिकार हर अनुरोध पर फिर से गणना किए जाते हैं, इसलिए बदलाव तुरंत लागू होता है।

read अनुदान ये कार्रवाइयाँ देता है: repository.read, artifact.read, artifact.list, content.read, package.read, asset.read और annotation.read। write अनुदान इन्हें जोड़ता है: upload.create, upload.read, upload.write, upload.complete, upload.cancel, job.read, package.publish, asset.write, asset.restore, annotation.write, reference.write, artifact.promote और audit.read। कार्रवाइयाँ artifact.delete, storage.read, storage.manage और diagnostics.read समूह से नहीं आ सकतीं: केवल सेवा कुंजी के पास ही हो सकती हैं।

रिपॉज़िटरी कार्रवाइयाँ

सेवा कुंजी सटीक कार्रवाइयाँ ले जाती है, रिपॉज़िटरी-दर-रिपॉज़िटरी। 24 हैं:

कार्रवाई	क्या अनुमति देती है
`repository.read`	रिपॉज़िटरी और उसकी मिरर स्थिति देखना।
`artifact.read`	आर्टिफ़ैक्ट का विवरण, स्टेज और प्रमोशन पढ़ना। आर्टिफ़ैक्ट में हर बदलाव के साथ भी चाहिए।
`artifact.list`	आर्टिफ़ैक्ट सूचीबद्ध और खोजना, स्टेज किए गए आर्टिफ़ैक्ट सूचीबद्ध करना, प्रमोशन जर्नल और परिवर्तन फ़ीड पढ़ना।
`artifact.promote`	स्टेज सेट और हटाना, और किसी दूसरी रिपॉज़िटरी में प्रमोट करना (कॉपी या स्थानांतरण)।
`artifact.delete`	आर्टिफ़ैक्ट हटाना, प्रतिधारण का पूर्वावलोकन और उसे लागू करना, और कंटेनर इमेज हटाना तथा Git LFS फ़ाइलों का ज़बरदस्ती अनलॉक करना।
`content.read`	ID, पैकेज या पथ से बाइट डाउनलोड करना, और डाउनलोड लिंक बनाना।
`upload.create`	अपलोड सत्र बनाना। रजिस्ट्री में पुश और Git LFS इसे इस्तेमाल करते हैं।
`upload.read`	अपने ही अपलोड सत्र और उनके भाग पढ़ना।
`upload.write`	अपने ही अपलोड के भाग या पूरी सामग्री भेजना।
`upload.complete`	अपना ही अपलोड पूरा करना, या उसकी पूर्णता को कतार में लगाना।
`upload.cancel`	अपना ही pending अपलोड रद्द करना।
`job.read`	अपने ही पूर्णता जॉब पढ़ना।
`package.read`	पैकेज सूचीबद्ध करना, संस्करण निर्धारित करना और पैकेज डाउनलोड करना।
`package.publish`	UPack आर्काइव को पैकेज के रूप में पंजीकृत करना।
`asset.read`	पथ वाली फ़ाइलें सूचीबद्ध करना और उनके पॉइंटर, इतिहास और संशोधन पढ़ना। बाइट डाउनलोड करने के लिए `content.read` चाहिए।
`asset.write`	किसी पथ को किसी आर्टिफ़ैक्ट पर इंगित करना, या रॉ फ़ाइल सहेजना।
`asset.restore`	पथ का पुराना संशोधन पुनर्स्थापित करना।
`annotation.read`	लेबल, मेटाडेटा, संग्रह और अटैचमेंट पढ़ना।
`annotation.write`	लेबल, मेटाडेटा, संग्रह और अटैचमेंट बदलना।
`reference.write`	आर्टिफ़ैक्ट की रक्षा करने वाले संदर्भ जोड़ना और हटाना।
`audit.read`	रिपॉज़िटरी का कैटलॉग ऑडिट पढ़ना।
`storage.read`	कोटा, उपयोग, स्टोरेज नीति और क्लीनअप सेटिंग्स पढ़ना।
`storage.manage`	स्टोरेज नीति और क्लीनअप सेटिंग्स बदलना, और क्लीनअप चलाना।
`diagnostics.read`	स्टोरेज इवेंट पढ़ना।

किसी ऑपरेशन को जिनकी ज़रूरत होती है वह सटीक समूह संदर्भ में उसकी पंक्ति पर होता है, उदाहरण के लिए putUploadContent के लिए upload.write और upload.complete। रिपॉज़िटरी में बदलाव के लिए उससे मेल खाती read कार्रवाई भी चाहिए, जैसे annotation.write के साथ artifact.read।

स्वामी की शर्तें अपलोड और जॉब पर लागू होती हैं: आप केवल उन अपलोड सत्रों और पूर्णता जॉब पर कार्य करते हैं जो आपके खाते ने बनाए। एक सेवा खाते की सभी कुंजियाँ, और एक व्यक्ति के सभी सत्र और टोकन, एक ही स्वामी माने जाते हैं। इसलिए एक रिपॉज़िटरी में कई सेवाएँ खातों और रिपॉज़िटरी से अलग होती हैं, पथ के प्रीफ़िक्स से नहीं।

प्रबंधन और सिस्टम अनुमतियाँ

अनुमति के दो अन्य प्रकार रिपॉज़िटरी कार्रवाइयाँ नहीं हैं। सात प्रबंधन कार्रवाइयाँ प्रत्यायोजन के अंतर्गत सूचीबद्ध हैं। दो सिस्टम अनुमतियाँ, backup.read और backup.manage, केवल व्यवस्थापकों और पुनर्प्राप्ति कुंजी की हैं।

सर्वर कोई भी पासवर्ड जाँचने से पहले पासवर्ड का अनुमान लगाना धीमा कर देता है। काउंटर हर API प्रोसेस की मेमोरी में रहते हैं और रीस्टार्ट के बाद फिर से शुरू होते हैं। वे प्रति क्लाइंट पते लागू होते हैं, और IPv6 पते को उसके /64 प्रीफ़िक्स से गिना जाता है। रिवर्स प्रॉक्सी के पीछे ARKVORY_TRUSTED_PROXIES सेट करें, वरना हर क्लाइंट प्रॉक्सी के रूप में दिखता है।

सीमा	मान
प्रति पते साइन-इन प्रयास	10 का बर्स्ट, फिर हर 15 सेकंड में एक और। सफल साइन-इन कोई प्रयास नहीं लेता।
प्रति खाता विफल पासवर्ड	हर गलत पासवर्ड एक ऐसे कर्ज़ में 1 जोड़ता है जो हर 6 सेकंड में 1 घटता है। 20 से ऊपर, खाता 1 सेकंड के लिए प्रयास अस्वीकार करता है, जो हर अगली विफलता के साथ दुगना होकर 2 मिनट तक जाता है; उस समय सही पासवर्ड को भी `429` मिलता है। सफल साइन-इन या रीसेट कर्ज़ माफ़ कर देता है।
प्रति पते पंजीकरण	3, फिर हर 20 मिनट में एक और।
प्रति सर्वर पंजीकरण	20, फिर हर 3 मिनट में एक और।
प्रगति में साइन-इन अनुरोध	प्रति API प्रोसेस 16, और बॉडी को आने के लिए 10 सेकंड हैं। अधिक होने पर कोड `busy` के साथ `503` लौटता है।

अस्वीकृत प्रयास 429 लौटाता है, कोड rate_limited, कारण login_attempts, registration_attempts या password_attempts, और Retry-After सेकंड में। उतनी प्रतीक्षा करें; लूप में दोबारा न आज़माएँ। पासवर्ड बदलने या रीसेट करने का अपना गेट और कारण password_attempts है। सभी साइन-इन, पंजीकरण, पासवर्ड परिवर्तन और टोकन परिवर्तन सुरक्षा ऑडिट (GET /api/v1/security/audit, केवल व्यवस्थापक) में लिखे जाते हैं, जो 365 दिन रखता है।

प्रमाणीकरण ​

एक नज़र में क्रेडेंशियल ​

हेडर प्रारूप ​

कंसोल साइन-इन सत्र ​

स्वयं-पंजीकरण ​

व्यक्तिगत एक्सेस टोकन ​

सेवा खाते और कुंजियाँ ​

सेवा कुंजियाँ ​

प्रत्यायोजन ​

पुनर्प्राप्ति कुंजी ​

डाउनलोड लिंक ​

एक्सेस नियम का अर्थ ​

रिपॉज़िटरी अनुमतियाँ ​

समूह अनुदान ​

रिपॉज़िटरी कार्रवाइयाँ ​

प्रबंधन और सिस्टम अनुमतियाँ ​

साइन-इन सीमाएँ ​

संबंधित पृष्ठ ​

प्रमाणीकरण

एक नज़र में क्रेडेंशियल

हेडर प्रारूप

कंसोल साइन-इन सत्र

स्वयं-पंजीकरण

व्यक्तिगत एक्सेस टोकन

सेवा खाते और कुंजियाँ

सेवा कुंजियाँ

प्रत्यायोजन

पुनर्प्राप्ति कुंजी

डाउनलोड लिंक

एक्सेस नियम का अर्थ

रिपॉज़िटरी अनुमतियाँ

समूह अनुदान

रिपॉज़िटरी कार्रवाइयाँ

प्रबंधन और सिस्टम अनुमतियाँ

साइन-इन सीमाएँ

संबंधित पृष्ठ