Gateway

प्रमाणीकरण क्रेडेंशियल के अर्थ-विज्ञान

ये सिमेंटिक्स चयन-समय और रनटाइम प्रमाणीकरण व्यवहार को संरेखित रखते हैं। इन्हें निम्नलिखित द्वारा साझा किया जाता है:

  • resolveAuthProfileOrder (प्रोफ़ाइल क्रम)
  • resolveApiKeyForProfile (रनटाइम क्रेडेंशियल समाधान)
  • openclaw models status --probe
  • openclaw doctor प्रमाणीकरण जाँचें (doctor-auth)

स्थिर प्रोब कारण कोड

प्रोब परिणामों में एक status बकेट (ok, auth, rate_limit, billing, timeout, format, unknown, no_model) और एक स्थिर reasonCode होता है, जब प्रोब कभी मॉडल कॉल तक नहीं पहुँचा:

reasonCode अर्थ
excluded_by_auth_order प्रोफ़ाइल को उसके प्रदाता के स्पष्ट प्रमाणीकरण क्रम से बाहर रखा गया है।
missing_credential कोई इनलाइन क्रेडेंशियल या SecretRef कॉन्फ़िगर नहीं किया गया है।
expired टोकन expires अतीत में है।
invalid_expires expires मान्य धनात्मक Unix ms टाइमस्टैम्प नहीं है।
unresolved_ref कॉन्फ़िगर किए गए SecretRef का समाधान नहीं किया जा सका।
ineligible_profile प्रोफ़ाइल प्रदाता कॉन्फ़िगरेशन के साथ असंगत है (इसमें विकृत कुंजी इनपुट शामिल है)।
no_model क्रेडेंशियल मौजूद हैं, लेकिन कोई प्रोब-योग्य मॉडल उम्मीदवार हल नहीं हुआ।

पात्रता जाँचें उपयोग-योग्य क्रेडेंशियल के कारण कोड के रूप में ok रिपोर्ट करती हैं।

टोकन क्रेडेंशियल

टोकन क्रेडेंशियल (type: "token") इनलाइन token और/या tokenRef का समर्थन करते हैं।

पात्रता नियम

  1. जब token और tokenRef दोनों अनुपस्थित हों, तो टोकन प्रोफ़ाइल अपात्र होती है (missing_credential)।
  2. expires वैकल्पिक है। मौजूद होने पर यह Unix epoch मिलीसेकंड की एक परिमित संख्या होनी चाहिए, जो 0 से अधिक और अधिकतम JavaScript Date टाइमस्टैम्प (8640000000000000) से अधिक न हो।
  3. यदि expires अमान्य है (गलत प्रकार, NaN, 0, ऋणात्मक, अपरिमित, या उस अधिकतम सीमा से परे), तो प्रोफ़ाइल invalid_expires के साथ अपात्र होती है।
  4. यदि expires अतीत में है, तो प्रोफ़ाइल expired के साथ अपात्र होती है।
  5. tokenRef, expires सत्यापन को बायपास नहीं करता।

समाधान नियम

  1. expires के लिए रिज़ॉल्वर सिमेंटिक्स पात्रता सिमेंटिक्स से मेल खाते हैं।
  2. पात्र प्रोफ़ाइलों के लिए, टोकन सामग्री को इनलाइन मान या tokenRef से हल किया जा सकता है।
  3. जिन रेफ़रेंस का समाधान नहीं हो सकता, वे models status --probe आउटपुट में unresolved_ref उत्पन्न करते हैं।

एजेंट कॉपी पोर्टेबिलिटी

एजेंट प्रमाणीकरण इनहेरिटेंस रीड-थ्रू होता है। जब किसी एजेंट की कोई स्थानीय प्रोफ़ाइल नहीं होती, तो वह गुप्त सामग्री को अपने क्रेडेंशियल स्टोर में कॉपी किए बिना रनटाइम पर डिफ़ॉल्ट/मुख्य एजेंट स्टोर से प्रोफ़ाइलों का समाधान करता है (agents/<agentId>/agent/openclaw-agent.sqlite)।

openclaw agents add जैसे स्पष्ट कॉपी प्रवाह इस पोर्टेबिलिटी नीति का उपयोग करते हैं:

  • api_key और token प्रोफ़ाइलें पोर्टेबल हैं, जब तक कि copyToAgents: false न हो।
  • oauth प्रोफ़ाइलें डिफ़ॉल्ट रूप से पोर्टेबल नहीं हैं, क्योंकि रिफ़्रेश टोकन एकल-उपयोग वाले या रोटेशन-संवेदी हो सकते हैं।
  • प्रदाता-स्वामित्व वाले OAuth प्रवाह केवल तभी copyToAgents: true के साथ ऑप्ट इन कर सकते हैं, जब एजेंटों के बीच रिफ़्रेश सामग्री की प्रतिलिपि बनाना सुरक्षित माना जाता हो; यह ऑप्ट-इन केवल तब लागू होता है, जब प्रोफ़ाइल में इनलाइन एक्सेस/रिफ़्रेश सामग्री हो।

गैर-पोर्टेबल प्रोफ़ाइलें रीड-थ्रू इनहेरिटेंस के माध्यम से उपलब्ध रहती हैं, जब तक कि लक्ष्य एजेंट अलग से साइन इन करके अपनी स्थानीय प्रोफ़ाइल न बना ले।

केवल-कॉन्फ़िगरेशन प्रमाणीकरण रूट

mode: "aws-sdk" वाली auth.profiles प्रविष्टियाँ रूटिंग मेटाडेटा हैं, संग्रहित क्रेडेंशियल नहीं। वे तब मान्य होती हैं, जब लक्ष्य प्रदाता models.providers.<id>.auth: "aws-sdk" का उपयोग करता है, जो Plugin-स्वामित्व वाला Amazon Bedrock सेटअप लिखता है। ये प्रोफ़ाइल आईडी auth.order और सत्र ओवरराइड में तब भी दिखाई दे सकती हैं, जब क्रेडेंशियल स्टोर में उनसे मेल खाने वाली कोई प्रविष्टि न हो।

क्रेडेंशियल स्टोर में type: "aws-sdk" न लिखें; संग्रहित क्रेडेंशियल केवल api_key, token, या oauth होते हैं। यदि किसी विरासती auth-profiles.json में ऐसा मार्कर है, तो openclaw doctor --fix उसे auth.profiles में ले जाता है और स्टोर से मार्कर हटा देता है।

स्पष्ट प्रमाणीकरण क्रम फ़िल्टरिंग

  • जब किसी प्रदाता के लिए auth.order.<provider> या प्रमाणीकरण-स्टोर क्रम ओवरराइड सेट होता है, तो models status --probe केवल उन प्रोफ़ाइल आईडी को प्रोब करता है, जो उस प्रदाता के हल किए गए प्रमाणीकरण क्रम में बनी रहती हैं। संग्रहित ओवरराइड, auth.order कॉन्फ़िगरेशन पर प्राथमिकता लेता है।
  • उस प्रदाता की ऐसी संग्रहित प्रोफ़ाइल, जिसे स्पष्ट क्रम से बाहर रखा गया है, बाद में चुपचाप आज़माई नहीं जाती। प्रोब आउटपुट इसे reasonCode: excluded_by_auth_order और विवरण Excluded by auth.order for this provider. के साथ रिपोर्ट करता है।

प्रोब लक्ष्य समाधान

  • प्रोब लक्ष्य प्रमाणीकरण प्रोफ़ाइलों, परिवेश क्रेडेंशियल, या models.json से आ सकते हैं (परिणाम source: profile, env, models.json)।
  • यदि किसी प्रदाता के पास क्रेडेंशियल हैं, लेकिन OpenClaw उसके लिए किसी प्रोब-योग्य मॉडल उम्मीदवार का समाधान नहीं कर सकता, तो models status --probe, reasonCode: no_model के साथ status: no_model रिपोर्ट करता है।

बाहरी CLI क्रेडेंशियल खोज

  • बाहरी CLI के स्वामित्व वाले केवल-रनटाइम क्रेडेंशियल (claude-cli के लिए Claude CLI, openai के लिए Codex CLI, minimax-portal के लिए MiniMax CLI) केवल तभी खोजे जाते हैं, जब प्रदाता, रनटाइम, या प्रमाणीकरण प्रोफ़ाइल वर्तमान कार्रवाई के दायरे में हो, अथवा उस बाहरी स्रोत की कोई संग्रहित स्थानीय प्रोफ़ाइल पहले से मौजूद हो।
  • प्रमाणीकरण-स्टोर कॉलर एक स्पष्ट बाहरी-CLI खोज मोड चुनते हैं: केवल स्थायी/Plugin प्रमाणीकरण के लिए none, पहले से संग्रहित बाहरी CLI प्रोफ़ाइलों को रिफ़्रेश करने के लिए existing, या प्रदाताओं/प्रोफ़ाइलों के किसी ठोस समुच्चय के लिए scoped
  • केवल-पठन/स्थिति पथ allowKeychainPrompt: false पास करते हैं; वे केवल फ़ाइल-समर्थित बाहरी CLI क्रेडेंशियल का उपयोग करते हैं और macOS Keychain परिणामों को न तो पढ़ते हैं, न दोबारा उपयोग करते हैं।

OAuth SecretRef नीति गार्ड

SecretRef इनपुट केवल स्थिर क्रेडेंशियल के लिए है। OAuth क्रेडेंशियल रनटाइम पर परिवर्तनशील होते हैं (रिफ़्रेश प्रवाह रोटेट किए गए टोकन सहेजते हैं), इसलिए SecretRef-समर्थित OAuth सामग्री परिवर्तनशील स्थिति को अलग-अलग स्टोर में बाँट देगी।

  • यदि कोई प्रोफ़ाइल क्रेडेंशियल type: "oauth" है, तो उस प्रोफ़ाइल के किसी भी क्रेडेंशियल सामग्री फ़ील्ड के लिए SecretRef ऑब्जेक्ट अस्वीकार कर दिए जाते हैं।
  • यदि auth.profiles.<id>.mode, "oauth" है, तो उस प्रोफ़ाइल के लिए SecretRef-समर्थित keyRef/tokenRef इनपुट अस्वीकार कर दिया जाता है।
  • स्टार्टअप/रीलोड गुप्त तैयारी और प्रोफ़ाइल समाधान पथों में उल्लंघन कठोर विफलताएँ (थ्रो की गई त्रुटियाँ) होते हैं।

विरासत-संगत संदेश

स्क्रिप्ट संगतता के लिए, प्रोब त्रुटियाँ इस पहली पंक्ति को अपरिवर्तित रखती हैं:

Auth profile credentials are missing or expired.

मानव-पठनीय विवरण और स्थिर कारण कोड बाद की पंक्तियों में ↳ Auth reason [code]: ... के रूप में आते हैं।

संबंधित

Was this useful?
On this page

On this page