आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी
क्या
'एपीआई पासकोड की पुष्टि करें' नीति की मदद से, रनटाइम के दौरान एपीआई पासकोड की पुष्टि की जा सकती है. इससे सिर्फ़ उन ऐप्लिकेशन को आपके एपीआई ऐक्सेस करने की अनुमति मिलती है जिनके एपीआई पासकोड को मंज़ूरी मिली है. इस नीति से यह पक्का होता है कि एपीआई पासकोड मान्य हैं, उन्हें रद्द नहीं किया गया है, और उन्हें आपके एपीआई प्रॉडक्ट से जुड़े खास संसाधनों का इस्तेमाल करने की अनुमति मिली है.
सैंपल
क्वेरी पैरामीटर में मौजूद कुंजियां
<VerifyAPIKey name="APIKeyVerifier">
<APIKey ref="request.queryparam.apikey" />
</VerifyAPIKey>इस उदाहरण में, नीति को request.queryparam.apikey नाम के फ़्लो वैरिएबल में एपीआई पासकोड मिलने की उम्मीद है. वैरिएबल request.queryparam.{name}, Edge का स्टैंडर्ड फ़्लो वैरिएबल है. इसमें क्लाइंट के अनुरोध में पास किए गए क्वेरी पैरामीटर की वैल्यू भरी जाती है.
यहां दी गई curl कमांड, क्वेरी पैरामीटर में एपीआई पासकोड पास करती है:
curl http://myorg-test.apigee.net/mocktarget?apikey=IEYRtW2cb7A5Gs54A1wKElECBL65GVls
हेडर में मौजूद कुंजियां
<VerifyAPIKey name="APIKeyVerifier">
<APIKey ref="request.header.x-apikey" />
</VerifyAPIKey>इस उदाहरण में, नीति को request.header.x-apikey नाम के फ़्लो वैरिएबल में एपीआई पासकोड मिलने की उम्मीद है. वैरिएबल request.header.{name}, Edge फ़्लो का एक स्टैंडर्ड वैरिएबल है. इसमें क्लाइंट के अनुरोध में पास किए गए हेडर की वैल्यू भरी जाती है.
यहां दिए गए cURL में, हेडर में एपीआई पासकोड पास करने का तरीका बताया गया है:
curl "http://myorg-test.apigee.net/mocktarget" -H "x-apikey:IEYRtW2cb7A5Gs54A1wKElECBL65GVls"
वैरिएबल में मौजूद कुंजी
<VerifyAPIKey name="APIKeyVerifier">
<APIKey ref="requestAPIKey.key"/>
</VerifyAPIKey>नीति में, कुंजी वाले किसी भी वैरिएबल का रेफ़रंस दिया जा सकता है. इस उदाहरण में दी गई नीति, requestAPIKey.key नाम के वैरिएबल से एपीआई पासकोड निकालती है.
उस वैरिएबल का डेटा कैसे जनरेट होता है, यह आप पर निर्भर करता है. उदाहरण के लिए, यहां दिए गए तरीके से, Extract Variables नीति का इस्तेमाल करके, myKey नाम के क्वेरी पैरामीटर से requestAPIKey.key को भरा जा सकता है:
<ExtractVariables async="false" continueOnError="false" enabled="true" name="SetAPIKeyVar">
<Source>request</Source>
<QueryParam name="myKey">
<Pattern ignoreCase="true">{key}</Pattern>
</QueryParam>
<VariablePrefix>requestAPIKey</VariablePrefix>
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>ऐक्सेस नीति के फ़्लो वैरिएबल
<AssignMessage async="false" continueOnError="false" enabled="true" name="accessverifyvars"> <AssignVariable> <Name>devFirstName</Name> <Ref>verifyapikey.verify-api-key.developer.firstName</Ref> <Value>ErrorOnCopy</Value> </AssignVariable> <AssignVariable> <Name>devLastName</Name> <Ref>verifyapikey.verify-api-key.developer.lastName</Ref> <Value>ErrorOnCopy</Value> </AssignVariable> <AssignVariable> <Name>devEmail</Name> <Ref>verifyapikey.verify-api-key.developer.email</Ref> <Value>ErrorOnCopy</Value> </AssignVariable> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
मान्य एपीआई पासकोड के लिए, Verify API Key नीति लागू करते समय, Edge अपने-आप फ़्लो वैरिएबल का एक सेट भर देता है. इन वैरिएबल का इस्तेमाल करके, ऐप्लिकेशन का नाम, ऐप्लिकेशन आईडी, और ऐप्लिकेशन रजिस्टर करने वाले डेवलपर या कंपनी की जानकारी ऐक्सेस की जा सकती है. ऊपर दिए गए उदाहरण में, Verify API Key के लागू होने के बाद, डेवलपर का पहला नाम, आखिरी नाम, और ईमेल पता ऐक्सेस करने के लिए, Assign Message नीति का इस्तेमाल किया जाता है.
इन सभी वैरिएबल के पहले यह प्रीफ़िक्स होता है:
verifyapikey.{policy_name}इस उदाहरण में, एपीआई पासकोड की पुष्टि करने की नीति का नाम "verify-api-key" है. इसलिए, अनुरोध करने वाले डेवलपर के नाम का पहला हिस्सा पाने के लिए, verifyapikey.verify-api-key.developer.firstName. वैरिएबल का इस्तेमाल किया जाता है
Edge के बारे में जानें
एपीआई कुंजी की पुष्टि करने से जुड़ी नीति के बारे में जानकारी
जब कोई डेवलपर Edge पर किसी ऐप्लिकेशन को रजिस्टर करता है, तो Edge अपने-आप उपभोक्ता कुंजी और सीक्रेट पेयर जनरेट करता है. Edge UI में ऐप्लिकेशन की उपभोक्ता कुंजी और सीक्रेट पेयर देखा जा सकता है. इसके अलावा, Edge API से भी इन्हें ऐक्सेस किया जा सकता है.
ऐप्लिकेशन रजिस्टर करते समय, डेवलपर ऐप्लिकेशन से जोड़ने के लिए एक या एक से ज़्यादा एपीआई प्रॉडक्ट चुनता है. एपीआई प्रॉडक्ट, संसाधनों का एक कलेक्शन होता है. इन संसाधनों को एपीआई प्रॉक्सी के ज़रिए ऐक्सेस किया जा सकता है. इसके बाद, डेवलपर हर अनुरोध में एपीआई कुंजी (उपयोगकर्ता कुंजी) को एपीआई प्रॉडक्ट के तौर पर पास करता है. यह एपीआई प्रॉडक्ट, ऐप्लिकेशन से जुड़ा होता है. ज़्यादा जानकारी के लिए, पब्लिश करने की खास जानकारी देखें.
एपीआई पासकोड का इस्तेमाल, पुष्टि करने वाले टोकन के तौर पर किया जा सकता है. इसके अलावा, इनका इस्तेमाल OAuth ऐक्सेस टोकन पाने के लिए भी किया जा सकता है. OAuth में, एपीआई कुंजियों को "क्लाइंट आईडी" कहा जाता है. इन नामों का इस्तेमाल एक-दूसरे की जगह पर किया जा सकता है. ज़्यादा जानकारी के लिए, OAuth होम देखें.
Verify API Key नीति लागू करते समय, Edge फ़्लो वैरिएबल का एक सेट अपने-आप भर देता है. ज़्यादा जानकारी के लिए, यहां दिए गए फ़्लो वैरिएबल देखें.
एलिमेंट का रेफ़रंस
इस नीति के लिए, इन एलिमेंट और एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है:
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key-1"> <DisplayName>Custom label used in UI</DisplayName> <APIKey ref="variable_containing_api_key"/> </VerifyAPIKey>
<VerifyAPIKey> एट्रिब्यूट
यहां दिए गए उदाहरण में, <VerifyAPIKey> टैग के एट्रिब्यूट दिखाए गए हैं:
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key-1">
यहां दी गई टेबल में, ऐसे एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट में एक जैसे होते हैं:
| एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी |
|---|---|---|---|
name |
नीति का अंदरूनी नाम. इसके अलावा, नीति को लेबल करने के लिए, |
लागू नहीं | ज़रूरी है |
continueOnError |
किसी नीति के काम न करने पर, गड़बड़ी दिखाने के लिए नीति के लागू होने के बाद भी फ़्लो को एक्ज़ीक्यूट करने के लिए, इसे |
गलत | वैकल्पिक |
enabled |
नीति को लागू करने के लिए, नीति को बंद करने के लिए, |
सही | वैकल्पिक |
async |
यह एट्रिब्यूट अब काम नहीं करता. |
गलत | बहिष्कृत |
<DisplayName> एलिमेंट
इस कॉलम में नीति को लेबल करने के लिए, name एट्रिब्यूट के साथ-साथ इस्तेमाल करें
मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर, जिसका नाम अलग और सामान्य भाषा में है.
<DisplayName>Policy Display Name</DisplayName>
| डिफ़ॉल्ट |
लागू नहीं अगर आप इस एलिमेंट को छोड़ देते हैं, तो नीति की |
|---|---|
| मौजूदगी | वैकल्पिक |
| टाइप | स्ट्रिंग |
<APIKey> एलिमेंट
यह एलिमेंट, उस फ़्लो वैरिएबल के बारे में बताता है जिसमें एपीआई पासकोड होता है. आम तौर पर, क्लाइंट एपीआई कुंजी को क्वेरी पैरामीटर, एचटीटीपी हेडर या फ़ॉर्म पैरामीटर में भेजता है. उदाहरण के लिए, अगर कुंजी को x-apikey नाम वाले हेडर में भेजा जाता है, तो कुंजी इस वैरिएबल में मिलेगी: request.header.x-apikey
| डिफ़ॉल्ट | NA |
|---|---|
| मौजूदगी | ज़रूरी है |
| टाइप | स्ट्रिंग |
विशेषताएं
यहां दी गई टेबल में, <APIKey> एलिमेंट के एट्रिब्यूट के बारे में बताया गया है
| एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी |
|---|---|---|---|
| ref |
यह उस वैरिएबल का रेफ़रंस है जिसमें एपीआई पासकोड होता है. हर नीति के लिए, सिर्फ़ एक जगह की जानकारी दी जा सकती है. |
लागू नहीं | ज़रूरी है |
उदाहरण
इन उदाहरणों में, पैरामीटर और x-apikey नाम के हेडर में कुंजी पास की जाती है.
क्वेरी पैरामीटर के तौर पर:
<VerifyAPIKey name="APIKeyVerifier">
<APIKey ref="request.queryparam.x-apikey"/>
</VerifyAPIKey>एचटीटीपी हेडर के तौर पर:
<VerifyAPIKey name="APIKeyVerifier">
<APIKey ref="request.header.x-apikey"/>
</VerifyAPIKey>एचटीटीपी फ़ॉर्म पैरामीटर के तौर पर:
<VerifyAPIKey name="APIKeyVerifier">
<APIKey ref="request.formparam.x-apikey"/>
</VerifyAPIKey>स्कीमा
फ़्लो वैरिएबल
जब किसी मान्य एपीआई कुंजी पर, एपीआई कुंजी की पुष्टि करने की नीति लागू की जाती है, तो Edge, फ़्लो वैरिएबल का एक सेट भरता है. ये वैरिएबल, फ़्लो में बाद में लागू होने वाली नीतियों या कोड के लिए उपलब्ध होते हैं. इनका इस्तेमाल अक्सर एपीआई पासकोड के एट्रिब्यूट के आधार पर कस्टम प्रोसेसिंग करने के लिए किया जाता है. जैसे, ऐप्लिकेशन का नाम, पासकोड को अनुमति देने के लिए इस्तेमाल किया गया एपीआई प्रॉडक्ट या एपीआई पासकोड के कस्टम एट्रिब्यूट.
नीति, कई तरह के फ़्लो वैरिएबल भरती है. इनमें ये शामिल हैं:
- सामान्य
- ऐप्लिकेशन
- डेवलपर
- कंपनी
- Analytics
हर तरह के फ़्लो वैरिएबल का प्रीफ़िक्स अलग होता है. सभी वैरिएबल स्केलर होते हैं. हालांकि, जिन वैरिएबल को खास तौर पर ऐरे के तौर पर दिखाया गया है वे स्केलर नहीं होते.
सामान्य फ़्लो वैरिएबल
यहां दी गई टेबल में, Verify API Key नीति से भरे गए सामान्य फ़्लो वैरिएबल की सूची दी गई है. इन सभी वैरिएबल के पहले यह प्रीफ़िक्स होता है:
verifyapikey.{policy_name}उदाहरण के लिए: verifyapikey.{policy_name}.client_id
उपलब्ध वैरिएबल में ये शामिल हैं:
| वैरिएबल | ब्यौरा |
|---|---|
client_id |
अनुरोध करने वाले ऐप्लिकेशन की ओर से दी गई उपभोक्ता कुंजी (इसे एपीआई पासकोड या ऐप्लिकेशन पासकोड भी कहा जाता है). |
client_secret |
उपयोगकर्ता कुंजी से जुड़ा उपभोक्ता सीक्रेट. |
redirection_uris |
अनुरोध में मौजूद कोई भी रीडायरेक्ट यूआरआई. |
developer.app.id |
अनुरोध करने वाले डेवलपर ऐप्लिकेशन का आईडी. |
developer.app.name |
अनुरोध करने वाले डेवलपर ऐप्लिकेशन का नाम. |
developer.id |
अनुरोध करने वाले ऐप्लिकेशन के मालिक के तौर पर रजिस्टर किए गए डेवलपर का आईडी. |
developer.{custom_attrib_name} |
ऐप्लिकेशन की मुख्य प्रोफ़ाइल से मिले कस्टम एट्रिब्यूट |
DisplayName |
नीति के <DisplayName> एट्रिब्यूट की वैल्यू. |
failed |
एपीआई पासकोड की पुष्टि न होने पर, इसे "true" पर सेट किया जाता है. |
{custom_app_attrib} |
ऐप्लिकेशन प्रोफ़ाइल से मिला कोई भी कस्टम एट्रिब्यूट. कस्टम एट्रिब्यूट का नाम बताएं. |
apiproduct.name* |
अनुरोध की पुष्टि करने के लिए इस्तेमाल किए गए एपीआई प्रॉडक्ट का नाम. |
apiproduct.{custom_attrib_name}* |
एपीआई प्रॉडक्ट प्रोफ़ाइल से मिला कोई भी कस्टम एट्रिब्यूट. |
apiproduct.developer.quota.limit* |
एपीआई प्रॉडक्ट के लिए तय की गई कोटा की सीमा. |
apiproduct.developer.quota.interval* |
एपीआई प्रॉडक्ट पर सेट किया गया कोटा इंटरवल. अगर कोई इंटरवल सेट नहीं किया गया है, तो यह फ़ील्ड मौजूद नहीं होगा. |
apiproduct.developer.quota.timeunit* |
अगर एपीआई प्रॉडक्ट पर कोटा टाइम यूनिट सेट है, तो यह उसकी जानकारी देता है. |
* अगर एपीआई प्रॉडक्ट को मान्य एनवायरमेंट, प्रॉक्सी, और संसाधनों (proxy.pathsuffix से लिए गए) के साथ कॉन्फ़िगर किया गया है, तो एपीआई प्रॉडक्ट के वैरिएबल अपने-आप भर जाते हैं. एपीआई प्रॉडक्ट सेट अप करने के निर्देशों के लिए, एपीआई पब्लिश करने के लिए Edge Management API का इस्तेमाल करना लेख पढ़ें. |
|
ऐप्लिकेशन फ़्लो के वैरिएबल
नीति के तहत, ऐप्लिकेशन के बारे में जानकारी देने वाले इन फ़्लो वैरिएबल को भरा जाता है. इन सभी वैरिएबल के पहले यह प्रीफ़िक्स होता है:
verifyapikey.{policy_name}.app.
उदाहरण के लिए:
verifyapikey.{policy_name}.app.name
उपलब्ध वैरिएबल में ये शामिल हैं:
| वैरिएबल | ब्यौरा |
|---|---|
name |
ऐप्लिकेशन का नाम. |
id |
ऐप्लिकेशन का आईडी. |
accessType |
Apigee इसका इस्तेमाल नहीं करता. |
callbackUrl |
ऐप्लिकेशन का कॉलबैक यूआरएल. आम तौर पर, इसका इस्तेमाल सिर्फ़ OAuth के लिए किया जाता है. |
DisplayName |
ऐप्लिकेशन का डिसप्ले नेम. |
status |
ऐप्लिकेशन की स्थिति, जैसे कि 'मंज़ूरी दी गई' या 'वापस ले ली गई'. |
apiproducts |
ऐसी कैटगरी जिसमें ऐप्लिकेशन से जुड़े एपीआई प्रॉडक्ट की सूची शामिल है. |
appFamily |
ऐप्लिकेशन शामिल करने वाला कोई भी ऐप्लिकेशन फ़ैमिली या "डिफ़ॉल्ट". |
appParentStatus |
ऐप्लिकेशन के पैरंट का स्टेटस, जैसे कि 'चालू है' या 'बंद है' |
appType |
ऐप्लिकेशन का टाइप, "कंपनी" या "डेवलपर" के तौर पर. |
appParentId |
पैरंट ऐप्लिकेशन का आईडी. |
created_at |
ऐप्लिकेशन बनाए जाने की तारीख/समय का स्टैंप. |
created_by |
ऐप्लिकेशन बनाने वाले डेवलपर का ईमेल पता. |
last_modified_at |
ऐप्लिकेशन को आखिरी बार अपडेट किए जाने की तारीख/टाइमस्टैंप. |
last_modified_by |
उस डेवलपर का ईमेल पता जिसने ऐप्लिकेशन को आखिरी बार अपडेट किया था. |
{app_custom_attributes} |
कस्टम ऐप्लिकेशन का कोई भी एट्रिब्यूट. कस्टम एट्रिब्यूट का नाम बताएं. |
डेवलपर फ़्लो वैरिएबल
नीचे दिए गए फ़्लो वैरिएबल में डेवलपर के बारे में जानकारी होती है. इन्हें नीति के तहत भरा जाता है. इन सभी वैरिएबल के पहले यह प्रीफ़िक्स होता है:
verifyapikey.{policy_name}.developerउदाहरण के लिए:
verifyapikey.{policy_name}.developer.id
उपलब्ध वैरिएबल में ये शामिल हैं:
| वैरिएबल | ब्यौरा |
|---|---|
id |
{org_name}@@@{developer_id} दिखाता है |
userName |
डेवलपर का उपयोगकर्ता नाम. |
firstName |
डेवलपर का नाम. |
lastName |
डेवलपर का उपनाम. |
email |
डेवलपर का ईमेल पता. |
status |
डेवलपर का स्टेटस, जैसे कि चालू है, बंद है या लॉगिन लॉक है. |
apps |
डेवलपर से जुड़े ऐप्लिकेशन की एक सूची. |
created_at |
डेवलपर खाता बनाए जाने की तारीख/समय का स्टैंप. |
created_by |
डेवलपर खाता बनाने वाले व्यक्ति का ईमेल पता. |
last_modified_at |
वह तारीख/टाइम स्टैंप जब डेवलपर में पिछली बार बदलाव किया गया था. |
last_modified_by |
डेवलपर खाते में बदलाव करने वाले उपयोगकर्ता का ईमेल पता. |
{developer_custom_attributes} |
डेवलपर की ओर से बनाया गया कोई भी कस्टम एट्रिब्यूट. कस्टम एट्रिब्यूट का नाम बताएं. |
Company |
डेवलपर से जुड़ी कंपनी का नाम. |
कंपनी के फ़्लो वैरिएबल
नीचे दिए गए फ़्लो वैरिएबल में, कंपनी के बारे में जानकारी होती है. इन्हें नीति के तहत भरा जाता है. इन सभी वैरिएबल के पहले यह प्रीफ़िक्स होता है:
verifyapikey.{policy_name}.companyउदाहरण के लिए:
verifyapikey.{policy_name}.company.nameउपलब्ध वैरिएबल में ये शामिल हैं:
| वैरिएबल | ब्यौरा |
|---|---|
name |
कंपनी का नाम. |
displayName |
कंपनी का डिसप्ले नेम. |
id |
कंपनी का आईडी. |
apps |
यह एक ऐसा कलेक्शन होता है जिसमें कंपनी के ऐप्लिकेशन की सूची होती है. |
appOwnerStatus |
ऐप्लिकेशन के मालिक का स्टेटस, जैसे कि चालू, बंद या login_lock.
|
created_at |
कंपनी बनाए जाने की तारीख/समय का स्टैंप. |
created_by |
कंपनी बनाने वाले उपयोगकर्ता का ईमेल पता. |
last_modified_at |
कंपनी में पिछली बार बदलाव किए जाने की तारीख/टाइम स्टैंप. |
last_modified_by |
कंपनी में आखिरी बार बदलाव करने वाले उपयोगकर्ता का ईमेल पता. |
{company_custom_attributes} |
कंपनी का कोई भी कस्टम एट्रिब्यूट. कस्टम एट्रिब्यूट का नाम बताएं. |
Analytics वैरिएबल
मान्य एपीआई पासकोड के लिए, 'एपीआई पासकोड की पुष्टि करें' नीति लागू होने पर, Analytics में ये वैरिएबल अपने-आप भर जाते हैं. इन वैरिएबल में सिर्फ़ 'एपीआई पासकोड की पुष्टि करें' नीति और OAuth नीतियां डेटा भरती हैं.
वैरिएबल और वैल्यू का इस्तेमाल डाइमेंशन के तौर पर किया जा सकता है. इससे Analytics रिपोर्ट बनाई जा सकती हैं. इन रिपोर्ट से, डेवलपर और ऐप्लिकेशन के इस्तेमाल के पैटर्न के बारे में जानकारी मिलती है.
- apiproduct.name
- developer.app.name
- client_id
- developer.id
गड़बड़ी की जानकारी
इस सेक्शन में, गड़बड़ी के कोड और गड़बड़ी के मैसेज के बारे में बताया गया है. साथ ही, उन गड़बड़ी वाले वैरिएबल के बारे में बताया गया है जिन्हें Edge सेट करता है. ऐसा तब होता है, जब यह नीति गड़बड़ी को ट्रिगर करती है. अगर आपको गड़बड़ियों को ठीक करने के लिए, गड़बड़ी से जुड़े नियम बनाने हैं, तो यह जानकारी आपके लिए ज़रूरी है. ज़्यादा जानने के लिए, नीति से जुड़ी गड़बड़ियों के बारे में ज़रूरी जानकारी और गड़बड़ियों को ठीक करना लेख पढ़ें.
रनटाइम से जुड़ी गड़बड़ियां
ये गड़बड़ियां, नीति लागू करते समय हो सकती हैं.
| गड़बड़ी का कोड | एचटीटीपी कोड स्थिति | वजह |
|---|---|---|
keymanagement.service.CompanyStatusNotActive |
401 | जिस डेवलपर ऐप्लिकेशन से जुड़ी कंपनी की एपीआई कुंजी का इस्तेमाल किया जा रहा है उसका स्टेटस 'चालू नहीं है' के तौर पर सेट है. जब किसी कंपनी का स्टेटस 'बंद है' पर सेट होता है, तब उस कंपनी से जुड़े डेवलपर या ऐप्लिकेशन को ऐक्सेस नहीं किया जा सकता. संगठन का एडमिन, मैनेजमेंट एपीआई का इस्तेमाल करके किसी कंपनी की स्थिति बदल सकता है. किसी कंपनी का स्टेटस सेट करना लेख पढ़ें. |
keymanagement.service.DeveloperStatusNotActive |
401 |
जिस डेवलपर ने उस डेवलपर ऐप्लिकेशन को बनाया है जिसमें इस्तेमाल की जा रही एपीआई कुंजी है उसका स्टेटस 'कार्रवाई नहीं की जा सकती' के तौर पर सेट है. जब किसी ऐप्लिकेशन डेवलपर के स्टेटस को 'इस्तेमाल में नहीं है' पर सेट किया जाता है, तो उस डेवलपर के बनाए गए सभी डेवलपर ऐप्लिकेशन बंद हो जाते हैं. एडमिन के तौर पर काम करने वाला कोई उपयोगकर्ता, डेवलपर की स्थिति में बदलाव कर सकता है. इसके लिए, उसके पास ज़रूरी अनुमतियां होनी चाहिए. जैसे, संगठन के एडमिन की अनुमति. वह डेवलपर की स्थिति में इन तरीकों से बदलाव कर सकता है:
|
keymanagement.service.invalid_client-app_not_approved |
401 | एपीआई पासकोड से जुड़े डेवलपर ऐप्लिकेशन का ऐक्सेस रद्द कर दिया गया है. जिस ऐप्लिकेशन का ऐक्सेस रद्द कर दिया गया है वह किसी भी एपीआई प्रॉडक्ट को ऐक्सेस नहीं कर सकता. साथ ही, Apigee Edge से मैनेज किए जाने वाले किसी भी एपीआई को शुरू नहीं कर सकता. संगठन का एडमिन, मैनेजमेंट एपीआई का इस्तेमाल करके डेवलपर ऐप्लिकेशन की स्थिति बदल सकता है. डेवलपर ऐप्लिकेशन को मंज़ूरी देना या उसे रद्द करना लेख पढ़ें. |
oauth.v2.FailedToResolveAPIKey |
401 | नीति के मुताबिक, एपीआई पासकोड को उस वैरिएबल में होना चाहिए जिसे नीति के <APIKey> एलिमेंट में तय किया गया है. यह गड़बड़ी तब होती है, जब अनुमानित वैरिएबल मौजूद नहीं होता (इसे ठीक नहीं किया जा सकता). |
oauth.v2.InvalidApiKey |
401 | Edge को एक एपीआई पासकोड मिला है, लेकिन वह अमान्य है. जब Edge अपने डेटाबेस में कुंजी खोजता है, तो यह ज़रूरी है कि वह अनुरोध में भेजी गई कुंजी से पूरी तरह मेल खाए. अगर एपीआई पहले काम करता था, तो पक्का करें कि कुंजी फिर से जनरेट न की गई हो. अगर कुंजी को फिर से जनरेट किया गया है, तो पुरानी कुंजी का इस्तेमाल करने पर आपको यह गड़बड़ी दिखेगी. ज़्यादा जानकारी के लिए, ऐप्लिकेशन रजिस्टर करना और एपीआई कुंजियां मैनेज करना लेख पढ़ें. |
oauth.v2.InvalidApiKeyForGivenResource |
401 | Edge को एक एपीआई पासकोड मिला है और यह मान्य है. हालांकि, यह उस डेवलपर ऐप्लिकेशन में मौजूद मंज़ूरी पा चुके पासकोड से मेल नहीं खाता है जो किसी प्रॉडक्ट के ज़रिए आपकी एपीआई प्रॉक्सी से जुड़ा है. |
डिप्लॉयमेंट से जुड़ी गड़बड़ियां
इस नीति का इस्तेमाल करने वाली प्रॉक्सी को डिप्लॉय करते समय, ये गड़बड़ियां हो सकती हैं.
| गड़बड़ी का नाम | वजह |
|---|---|
SpecifyValueOrRefApiKey |
<APIKey> एलिमेंट के लिए, वैल्यू या कुंजी तय नहीं की गई है. |
फ़ॉल्ट वैरिएबल
ये वैरिएबल, रनटाइम में गड़बड़ी होने पर सेट किए जाते हैं. ज़्यादा जानकारी के लिए, नीति के उल्लंघन से जुड़ी गड़बड़ियों के बारे में ज़रूरी जानकारी लेख पढ़ें.
| वैरिएबल | कहां | उदाहरण |
|---|---|---|
fault.name="fault_name" |
fault_name गड़बड़ी का नाम है. इसके बारे में ऊपर दी गई रनटाइम से जुड़ी गड़बड़ियां टेबल में बताया गया है. गड़बड़ी का नाम, गड़बड़ी के कोड का आखिरी हिस्सा होता है. | fault.name Matches "FailedToResolveAPIKey" |
oauthV2.policy_name.failed |
policy_name, नीति का वह नाम है जिसे उपयोगकर्ता ने तय किया है और जिसकी वजह से गड़बड़ी हुई है. | oauthV2.VK-VerifyAPIKey.failed = true |
गड़बड़ी के जवाबों के उदाहरण
{
"fault":{
"faultstring":"Invalid ApiKey",
"detail":{
"errorcode":"oauth.v2.InvalidApiKey"
}
}
}{
"fault":{
"detail":{
"errorcode":"keymanagement.service.DeveloperStatusNotActive"
},
"faultstring":"Developer Status is not Active"
}
}गड़बड़ी के नियम का उदाहरण
<FaultRule name="FailedToResolveAPIKey">
<Step>
<Name>AM-FailedToResolveAPIKey</Name>
</Step>
<Condition>(fault.name Matches "FailedToResolveAPIKey") </Condition>
</FaultRule>