CLI प्रमाणीकरण
नेटिव Cloud PKCE से साइन इन करें और उस सत्र को पुराने API और DDS सेवा क्रेडेंशियल से अलग रखें।
CLI प्रमाणीकरण
यह दस्तावेज़ DDS CLI और Cloud सेवाओं के लिए प्रमाणीकरण और अनुमति प्रबंधन का विवरण देता है।
ब्राउज़र साइन इन और टोकन एक्सचेंज
जब आप CLI में साइन इन करते हैं, तो एक सुरक्षित ब्राउज़र विंडो खुलती है। प्रमाणीकरण पूरा करने के बाद, एक स्थानीय कॉलबैक टोकन प्राप्त करता है। टोकन सुरक्षित ऑपरेटिंग सिस्टम स्टोर में सहेजा जाता है। | क्रेडेंशियल मार्ग | अधिकार |
|---|---|---|
Digital Design Studio 2.0.2 Windows | सुरक्षित स्थानीय सुविधाओं के लिए ब्राउज़र साइन इन; संपादन और सहेजना साइन इन के बिना भी काम करते हैं | कोई My PC डिवाइस लाइसेंस नहीं। Free साइन इन प्रलेखित स्थानीय सुविधाओं का समर्थन करता है; Cloud और AI अलग-अलग अनुमतियों की जाँच करते हैं। |
| ब्राउज़र PKCE और निजी CLI सत्र | खाता पहचान तथा संगठन/प्रोजेक्ट अनुमतियाँ सर्वर जाँचता है |
ग्राहक कार्रवाई/जॉब क्लाइंट |
| चुने गए API को प्रस्तुत क्रेडेंशियल और स्कोप |
| कॉन्फ़िगर सेवा origin और | पुरानी सेवा का मौजूदा प्राधिकरण अनुबंध |
कोई CLI सत्र डेस्कटॉप लाइसेंस नहीं देता। नेटिव Cloud अनुरोध में डेस्कटॉप सत्र फ़ाइल, ब्राउज़र कुकी या आंतरिक सेवा हेडर आयात न करें।
नेटिव Cloud साइन इन
alti ide cloud login
alti ide cloud whoami
alti ide cloud refresh
alti ide cloud logout
लॉगिन ब्राउज़र PKCE प्रवाह का प्राधिकरण URL प्रिंट करता है। इसका डिफ़ॉल्ट https://api.altifigence.com और निजी सत्र डायरेक्टरी ~/.local/state/altifigence/cloud-cli है। दूसरा सत्र चुनने के लिए --session-dir लगातार उपयोग करें। लॉगिन --org और सीमित --wait-seconds भी स्वीकार करता है; बाद के कमांड की अपनी अनुरोध समय सीमा होती है।
संग्रहीत टोकन से अनुमान लगाने के बजाय सर्वर पहचान के लिए whoami उपयोग करें। रीफ़्रेश और लॉगआउट इस नेटिव सत्र पर काम करते हैं। Cloud खोज और टर्मिनल कमांड पर संगठन/प्रोजेक्ट ID अनुरोध का स्कोप तय करती हैं, पर पहुँच नहीं दे सकतीं। टाइप किए ide cloud run ऑपरेशन सर्वर अनुमति जाँच बनाए रखते हैं और उनके अनुबंध में अपलोड स्रोत शामिल हो तो --allow-source-upload आवश्यक करते हैं।
CLI अपने स्पष्ट नेटिव API रूट से कनेक्ट होता है। साइन इन प्रवाह हर संगठन के लिए हर Cloud ऑपरेशन सक्षम होने का वादा नहीं है।
CLI द्वारा पढ़े जाने वाले एनवायरनमेंट वैरिएबल
पुराने ग्राहक कार्रवाई और Cloud जॉब क्लाइंट ये सेटिंग रखते हैं:
वैरिएबल | प्रभाव |
|---|---|
| आवश्यक bearer क्रेडेंशियल; गायब या खाली मान अस्वीकार होता है |
| आवश्यक संगठन स्कोप |
| API आधार, डिफ़ॉल्ट |
|
|
| स्रोत वाले ग्राहक MCP कार्यों के लिए स्पष्ट अनुमति; अनुपस्थित होने का अर्थ निषेध है |
एंडपॉइंट ओवरराइड केवल अपने नियंत्रण की सेवा या खाते के लिए स्पष्ट रूप से दिए एंडपॉइंट पर सेट करें। origin बदलने से संबंधित क्रेडेंशियल दूसरे होस्ट को जा सकता है।
पुराने DDS HTTP कमांड इसके बजाय --endpoint या ALTI_STUDIO_ENDPOINT और मौजूदा सेवा सीक्रेट एनवायरनमेंट सेटिंग उपयोग करते हैं। वे नेटिव Cloud लॉगिन फिर उपयोग नहीं करते और उस सेवा के लिए नया प्रमाणीकरण प्रवाह नहीं गढ़ते।
कॉन्फ़िगरेशन स्थिति प्रमाणीकरण नहीं है
alti auth status केवल पुराने एनवायरनमेंट कॉन्फ़िगरेशन की जाँच करता है। उसका serverVerification मान not_performed रहता है; यह alti ide cloud whoami के बराबर नहीं है।
पुराने शीर्ष स्तर के alti login और alti whoami अब भी 4 के साथ AUTH_FLOW_UNAVAILABLE और IDENTITY_NOT_VERIFIED देकर बाहर निकलते हैं। शीर्ष स्तर का alti logout मूल प्रक्रिया से मिले मान साफ़ नहीं कर सकता। उन्हें उनके स्रोत पर साफ़ या रोटेट करें; नेटिव सत्र के लिए ide cloud logout उपयोग करें।
सीक्रेट सँभालना
CI क्रेडेंशियल CI सीक्रेट स्टोर में रखें और केवल आवश्यक चरण में इंजेक्ट करें।
सत्र डायरेक्टरी केवल स्वामी के लिए निजी रखें; उन्हें स्रोत नियंत्रण, उपयोगकर्ताओं के बीच साझा कैश या प्रकाशित आर्टिफ़ैक्ट में न जोड़ें।
टोकन, सेवा सीक्रेट, ब्राउज़र कुकी या पूरा एनवायरनमेंट लॉग न करें।
क्रेडेंशियल वाले कमांड के आसपास शेल ट्रेसिंग अक्षम करें और लॉग में गया हो सकने वाला कोई भी मान रोटेट करें।
रिमोट API पहुँच
अपने चुने बैकएंड के लिए टाइप किए जॉब और Cloud कमांड उपयोग करें। क्लाइंट सत्यापन और सफल लॉगिन सर्वर अनुमति का स्थान नहीं लेते और अनुरोधित जॉब पूरा होने का प्रमाण नहीं हैं।
नेटिव सत्र सत्यापित और पुनर्प्राप्त करें
alti ide cloud login
alti ide cloud whoami
इन्हें उसी सामान्य Linux उपयोगकर्ता के रूप में चलाएँ जो CLI उपयोग करेगा। ब्राउज़र प्रवाह पूरा करें और वर्कस्पेस ऑपरेशन से पहले सफल whoami जवाब आवश्यक मानें। वैकल्पिक --session-dir उपयोग करें तो लॉगिन और बाद की कॉल में भी वही उपयोग करें; अलग डायरेक्टरी अलग सहेजा हुआ सत्र है।
सत्र समाप्त हो तो नेटिव रीफ़्रेश/साइन इन प्रवाह उपयोग करें। पहचान सफल हो लेकिन प्रोजेक्ट अस्वीकृत हो तो संगठन सदस्यता और प्रोजेक्ट अनुमति देखें। अस्वीकृति से बचने के लिए डेस्कटॉप क्रेडेंशियल कॉपी न करें और API origin न बदलें। खाता पुनर्प्राप्ति के लिए खाता सुरक्षा उपयोग करें।