আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান । তথ্য

কি
OAuthV2 হল OAuth 2.0 অনুদান টাইপ অপারেশন সম্পাদনের জন্য একটি বহুমুখী নীতি৷ এটি Apigee Edge-এ OAuth 2.0 এন্ডপয়েন্ট কনফিগার করতে ব্যবহৃত প্রাথমিক নীতি।
টিপ: আপনি যদি Apigee Edge-এ OAuth সম্পর্কে আরও জানতে চান, OAuth হোম পেজ দেখুন। এটি সম্পদ, নমুনা, ভিডিও এবং আরও অনেক কিছুর লিঙ্ক প্রদান করে। একটি কার্যকরী অ্যাপ্লিকেশনে এই নীতিটি কীভাবে ব্যবহার করা হয় তার একটি ভাল প্রদর্শনের জন্য GitHub-এ উন্নত OAuth নমুনা দেখুন।
নমুনা
AccessToken যাচাই করুন
AccessToken যাচাই করুন
এই OAuthV2 নীতি কনফিগারেশন (VerifyAccessToken অপারেশন সহ) যাচাই করে যে Apigee Edge এ জমা দেওয়া একটি অ্যাক্সেস টোকেন বৈধ। যখন এই নীতি অপারেশন ট্রিগার হয়, এজ অনুরোধে একটি বৈধ অ্যাক্সেস টোকেন খোঁজে। অ্যাক্সেস টোকেন বৈধ হলে, অনুরোধটি এগিয়ে যাওয়ার অনুমতি দেওয়া হয়। অবৈধ হলে, সমস্ত প্রক্রিয়াকরণ বন্ধ হয়ে যায় এবং প্রতিক্রিয়াতে একটি ত্রুটি ফিরে আসে।
<OAuthV2 async="false" continueOnError="false" enabled="true" name="OAuth-v20-2"> <DisplayName>OAuth v2.0 2</DisplayName> <Operation>VerifyAccessToken</Operation> <AccessTokenPrefix>Bearer</AccessTokenPrefix> <!-- Optional, default is Bearer --> </OAuthV2>
দ্রষ্টব্য: শুধুমাত্র OAuth 2.0 বহনকারী টোকেন সমর্থিত। বার্তা প্রমাণীকরণ কোড (MAC) টোকেন সমর্থিত নয়।
যেমন:
$ curl -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282
ডিফল্টরূপে, এজ Bearer
উপসর্গ সহ Authorization
শিরোনামে অ্যাক্সেস টোকেন গ্রহণ করে। আপনি <AccessToken>
উপাদান দিয়ে এই ডিফল্ট পরিবর্তন করতে পারেন।
অ্যাক্সেস টোকেন তৈরি করুন
অ্যাক্সেস টোকেন তৈরি করা হচ্ছে
প্রতিটি সমর্থিত অনুদান প্রকারের জন্য কীভাবে অ্যাক্সেস টোকেনগুলির জন্য অনুরোধ করা যায় তা দেখানো উদাহরণগুলির জন্য, অ্যাক্সেস টোকেন এবং অনুমোদনের কোডগুলির অনুরোধ করা দেখুন৷ বিষয়ের মধ্যে এই অপারেশনগুলির উদাহরণ রয়েছে:
অথরাইজেশন কোড তৈরি করুন
অনুমোদন কোড তৈরি করুন
অনুমোদন কোডের অনুরোধ কিভাবে দেখাতে হয় তার উদাহরণের জন্য, একটি অনুমোদন কোড অনুরোধ করা দেখুন।
রিফ্রেশ অ্যাক্সেস টোকেন
একটি অ্যাক্সেস টোকেন রিফ্রেশ করুন
রিফ্রেশ টোকেন ব্যবহার করে অ্যাক্সেস টোকেন কীভাবে অনুরোধ করা যায় তা দেখানো উদাহরণের জন্য, একটি অ্যাক্সেস টোকেন রিফ্রেশ করা দেখুন।
প্রতিক্রিয়া প্রবাহ টোকেন
প্রতিক্রিয়া প্রবাহে একটি অ্যাক্সেস টোকেন তৈরি করুন
কখনও কখনও আপনাকে প্রতিক্রিয়া প্রবাহে একটি অ্যাক্সেস টোকেন তৈরি করতে হতে পারে। উদাহরণস্বরূপ, আপনি ব্যাকএন্ড পরিষেবাতে করা কিছু কাস্টম বৈধতার প্রতিক্রিয়া হিসাবে এটি করতে পারেন। এই উদাহরণে, ব্যবহারের ক্ষেত্রে একটি অ্যাক্সেস টোকেন এবং একটি রিফ্রেশ টোকেন উভয়ই প্রয়োজন, অন্তর্নিহিত অনুদানের ধরনটি বাতিল করে। এই ক্ষেত্রে, আমরা টোকেন তৈরি করতে পাসওয়ার্ড অনুদানের ধরন ব্যবহার করব। আপনি দেখতে পাবেন, এই কাজটি করার কৌশলটি হল একটি জাভাস্ক্রিপ্ট নীতি সহ একটি অনুমোদনের অনুরোধ শিরোনামে পাস করা।
প্রথমে, আসুন নমুনা নীতিটি দেখি:
<OAuthV2 enabled="true" continueOnError="false" async="false" name="generateAccessToken"> <Operation>GenerateAccessToken</Operation> <AppEndUser>Doe</AppEndUser> <UserName>jdoe</UserName> <PassWord>jdoe</PassWord> <GrantType>grant_type</GrantType> <ClientId>a_valid_client_id</ClientId> <SupportedGrantTypes> <GrantType>password</GrantType> </SupportedGrantTypes> </OAuthV2>
আপনি যদি এই নীতিটি প্রতিক্রিয়া প্রবাহের উপর রাখেন, তবে এটি একটি 401 অননুমোদিত ত্রুটির সাথে ব্যর্থ হবে যদিও নীতিতে সঠিক লগইন পরামিতিগুলি নির্দিষ্ট করা আছে৷ এই সমস্যা সমাধানের জন্য, আপনাকে একটি অনুমোদন অনুরোধ শিরোনাম সেট করতে হবে।
অনুমোদন শিরোনামে অবশ্যই বেস64-এনকোডেড ক্লায়েন্ট_আইডি:ক্লায়েন্ট_সিক্রেট সহ একটি মৌলিক অ্যাক্সেস স্কিম থাকতে হবে।
আপনি OAuthV2 নীতির ঠিক আগে জাভাস্ক্রিপ্ট নীতির সাথে এই শিরোনামটি যোগ করতে পারেন, যেমন। "local_clientid" এবং "local_secret" ভেরিয়েবল অবশ্যই আগে সেট করা এবং প্রবাহে উপলব্ধ থাকতে হবে:
var client_id = context.getVariable("local_clientid"); var client_secret = context.getVariable("local_secret"); context.setVariable("request.header.Authorization","Basic "+CryptoJS.enc.Base64.stringify(CryptoJS.enc.Latin1 .parse(client_id + ':' + client_secret)));
এছাড়াও দেখুন " এনকোডিং মৌলিক প্রমাণীকরণ শংসাপত্র "।
উপাদান রেফারেন্স
নীতির রেফারেন্স OAuthV2 নীতির উপাদান এবং বৈশিষ্ট্য বর্ণনা করে।
নীচে দেখানো নমুনা নীতি অনেক সম্ভাব্য কনফিগারেশনের মধ্যে একটি। এই নমুনাটি GenerateAccessToken অপারেশনের জন্য কনফিগার করা একটি OAuthV2 নীতি দেখায়। এটি প্রয়োজনীয় এবং ঐচ্ছিক উপাদান অন্তর্ভুক্ত. বিস্তারিত জানার জন্য এই বিভাগে উপাদান বিবরণ পড়ুন.
<OAuthV2 name="GenerateAccessToken"> <!-- This policy generates an OAuth 2.0 access token using the client_credentials grant type --> <Operation>GenerateAccessToken</Operation> <!-- This is in millseconds, so expire in an hour --> <ExpiresIn>3600000</ExpiresIn> <SupportedGrantTypes> <GrantType>client_credentials</GrantType> </SupportedGrantTypes> <GrantType>request.queryparam.grant_type</GrantType> <GenerateResponse/> </OAuthV2>
<OAuthV2> বৈশিষ্ট্য
<OAuthV2 async="false" continueOnError="false" enabled="true" name="MyOAuthPolicy">
নিম্নলিখিত সারণী সমস্ত নীতির মূল উপাদানগুলির জন্য সাধারণ বৈশিষ্ট্যগুলি বর্ণনা করে:
বৈশিষ্ট্য | বর্ণনা | ডিফল্ট | উপস্থিতি |
---|---|---|---|
name | নীতির অভ্যন্তরীণ নাম। ঐচ্ছিকভাবে, ম্যানেজমেন্ট UI প্রক্সি এডিটরে নীতিটিকে একটি ভিন্ন, প্রাকৃতিক-ভাষা নামের সাথে লেবেল করতে | N/A | প্রয়োজন |
continueOnError | একটি নীতি ব্যর্থ হলে একটি ত্রুটি ফেরত দিতে একটি নীতি ব্যর্থ হওয়ার পরেও ফ্লো এক্সিকিউশন চালিয়ে যেতে | মিথ্যা | ঐচ্ছিক |
enabled | নীতি প্রয়োগ করতে নীতি বন্ধ করতে | সত্য | ঐচ্ছিক |
async | এই বৈশিষ্ট্যটি অবমূল্যায়ন করা হয়েছে৷ | মিথ্যা | অবচয় |
<DisplayName> উপাদান
ম্যানেজমেন্ট UI প্রক্সি এডিটরে নীতিটিকে একটি ভিন্ন, প্রাকৃতিক-ভাষা নামের সাথে লেবেল করতে name
বৈশিষ্ট্য ছাড়াও ব্যবহার করুন।
<DisplayName>Policy Display Name</DisplayName>
ডিফল্ট | N/A আপনি এই উপাদানটি বাদ দিলে, নীতির |
---|---|
উপস্থিতি | ঐচ্ছিক |
টাইপ | স্ট্রিং |
<AccessToken> উপাদান
<AccessToken>request.header.access_token</AccessToken>
ডিফল্টরূপে, VerifyAccessToken আশা করে যে Authorization
শিরোনামে অ্যাক্সেস টোকেন পাঠানো হবে। আপনি এই উপাদান ব্যবহার করে যে ডিফল্ট পরিবর্তন করতে পারেন. উদাহরণস্বরূপ, request.queryparam.access_token
নির্দেশ করে যে অ্যাক্সেস টোকেনটি access_token
নামের একটি ক্যোয়ারী প্যারামিটার হিসাবে উপস্থিত থাকা উচিত।
<AccessToken>request.header.access_token</AccessToken>
নির্দিষ্ট করা আছে:curl https://myorg-myenv.apigee.net/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"
<AccessToken>request.queryparam.access_token</AccessToken>
নির্দিষ্ট করা আছে:curl "https://myorg-myenv.apigee.net/oauth2/validate?access_token:Rft3dqrs56Blirls56a"
ডিফল্ট: | N/A |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
অপারেশনের সাথে ব্যবহার করা হয়: |
|
<AccessTokenPrefix> উপাদান
<AccessTokenPrefix>Bearer</AccessTokenPrefix>
ডিফল্টরূপে, VerifyAccessToken প্রত্যাশা করে যে অ্যাক্সেস টোকেনটি একটি অনুমোদন শিরোনামে একটি বহনকারী টোকেন হিসাবে পাঠানো হবে। যেমন:
-H "Authorization: Bearer Rft3dqrs56Blirls56a"
বর্তমানে, Bearer হল একমাত্র সমর্থিত উপসর্গ।
ডিফল্ট: | বহনকারী |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | বহনকারী |
অপারেশনের সাথে ব্যবহার করা হয়: |
|
<AppEndUser> উপাদান
<AppEndUser>request.queryparam.app_enduser</AppEndUser>
যে ক্ষেত্রে অ্যাপের শেষ ব্যবহারকারীর আইডি অবশ্যই অনুমোদন সার্ভারে পাঠানো হবে, এই উপাদানটি আপনাকে নির্দিষ্ট করতে দেয় যে প্রান্তটি শেষ ব্যবহারকারী আইডি কোথায় সন্ধান করবে। উদাহরণস্বরূপ, এটি একটি ক্যোয়ারী প্যারামিটার হিসাবে বা একটি HTTP শিরোনামে পাঠানো যেতে পারে।
উদাহরণস্বরূপ, request.queryparam.app_enduser
নির্দেশ করে যে AppEndUser একটি ক্যোয়ারী প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, ?app_enduser=ntesla@theramin.com
। একটি HTTP হেডারে AppEndUser প্রয়োজন করতে, উদাহরণস্বরূপ, এই মানটি request.header.app_enduser
এ সেট করুন।
এই সেটিং প্রদান করা আপনাকে অ্যাক্সেস টোকেনে একটি অ্যাপের শেষ ব্যবহারকারী আইডি অন্তর্ভুক্ত করতে সক্ষম করে। আপনি যদি শেষ ব্যবহারকারী আইডি দ্বারা OAuth 2.0 অ্যাক্সেস টোকেনগুলি পুনরুদ্ধার করতে বা প্রত্যাহার করতে সক্ষম হতে চান তবে এই বৈশিষ্ট্যটি কার্যকর। আরও তথ্যের জন্য, শেষ ব্যবহারকারী আইডি, অ্যাপ আইডি বা উভয় দ্বারা OAuth 2.0 অ্যাক্সেস টোকেনগুলির পুনরুদ্ধার এবং প্রত্যাহার সক্ষম করুন দেখুন৷
ডিফল্ট: | N/A |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোনো ফ্লো ভেরিয়েবল। |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<অ্যাট্রিবিউটস/অ্যাট্রিবিউট>
<Attributes> <Attribute name="attr_name1" ref="flow.variable" display="true|false">value1</Attribute> <Attribute name="attr_name2" ref="flow.variable" display="true|false">value2</Attribute> </Attributes>
একটি অ্যাক্সেস টোকেন বা অনুমোদন কোড কাস্টম বৈশিষ্ট্য যোগ করতে এই উপাদান ব্যবহার করুন. উদাহরণস্বরূপ, আপনি একটি অ্যাক্সেস টোকেনে একটি ব্যবহারকারী আইডি বা সেশন শনাক্তকারী এম্বেড করতে চাইতে পারেন যা রানটাইমে বের করা এবং চেক করা যেতে পারে।
এই উপাদানটি আপনাকে একটি ফ্লো ভেরিয়েবল বা আক্ষরিক স্ট্রিং থেকে একটি মান নির্দিষ্ট করতে দেয়। আপনি একটি ভেরিয়েবল এবং একটি স্ট্রিং উভয় নির্দিষ্ট করলে, ফ্লো ভেরিয়েবলে নির্দিষ্ট মান ব্যবহার করা হয়। যদি পরিবর্তনশীলটি সমাধান করা না যায়, তাহলে স্ট্রিংটি ডিফল্ট।
এই উপাদানটি ব্যবহার করার বিষয়ে আরও তথ্যের জন্য, টোকেন এবং অনুমোদনের কোডগুলি কাস্টমাইজ করা দেখুন।
প্রতিক্রিয়ায় কাস্টম বৈশিষ্ট্যগুলি প্রদর্শন করা বা লুকানো
মনে রাখবেন যে আপনি যদি এই নীতির GenerateResponse উপাদানটিকে সত্যে সেট করেন, টোকেনের সম্পূর্ণ JSON উপস্থাপনা প্রতিক্রিয়াতে ফেরত দেওয়া হয়, আপনার সেট করা যেকোনো কাস্টম বৈশিষ্ট্য সহ। কিছু ক্ষেত্রে, আপনি প্রতিক্রিয়াতে আপনার কিছু বা সমস্ত কাস্টম বৈশিষ্ট্য লুকিয়ে রাখতে চাইতে পারেন যাতে সেগুলি ক্লায়েন্ট অ্যাপগুলিতে দৃশ্যমান না হয়।
ডিফল্টরূপে, কাস্টম বৈশিষ্ট্য প্রতিক্রিয়ায় উপস্থিত হয়। আপনি যদি সেগুলি লুকিয়ে রাখতে চান, আপনি প্রদর্শনের প্যারামিটারটিকে মিথ্যাতে সেট করতে পারেন। যেমন:
<Attributes> <Attribute name="employee_id" ref="employee.id" display="false"/> <Attribute name="employee_name" ref="employee.name" display="false"/> </Attributes>
display
বৈশিষ্ট্যের মান স্থায়ী হয় না। ধরা যাক আপনি কাস্টম বৈশিষ্ট্য সহ একটি অ্যাক্সেস টোকেন তৈরি করেছেন যা আপনি জেনারেট করা প্রতিক্রিয়াতে লুকাতে চান। display=false
সেট করা সেই লক্ষ্যটি পূরণ করে। যাইহোক, যদি রিফ্রেশ টোকেন ব্যবহার করে একটি নতুন অ্যাক্সেস টোকেন তৈরি করা হয়, তবে অ্যাক্সেস টোকেন থেকে আসল কাস্টম বৈশিষ্ট্যগুলি রিফ্রেশ টোকেন প্রতিক্রিয়াতে প্রদর্শিত হবে। এর কারণ হল এজ মনে রাখে না যে display
অ্যাট্রিবিউটটি মূলত জেনারেট অ্যাক্সেস টোকেন নীতিতে false
সেট করা হয়েছিল--কাস্টম অ্যাট্রিবিউটটি কেবল অ্যাক্সেস টোকেনের মেটাডেটার অংশ।
আপনি একই আচরণ দেখতে পাবেন যদি আপনি একটি অনুমোদন কোডে কাস্টম বৈশিষ্ট্য যোগ করেন--যখন সেই কোডটি ব্যবহার করে একটি অ্যাক্সেস টোকেন তৈরি করা হয়, সেই কাস্টম বৈশিষ্ট্যগুলি অ্যাক্সেস টোকেন প্রতিক্রিয়াতে প্রদর্শিত হবে৷ আবার, এটি আপনার ইচ্ছাকৃত আচরণ নাও হতে পারে।
এই ক্ষেত্রে কাস্টম বৈশিষ্ট্যগুলি লুকানোর জন্য, আপনার কাছে এই পছন্দগুলি রয়েছে:
- রিফ্রেশ টোকেন নীতিতে কাস্টম বৈশিষ্ট্যগুলি স্পষ্টভাবে পুনরায় সেট করুন এবং তাদের প্রদর্শনকে মিথ্যাতে সেট করুন৷ এই ক্ষেত্রে, আপনাকে GetOAuthV2Info নীতি ব্যবহার করে আসল অ্যাক্সেস টোকেন থেকে আসল কাস্টম মানগুলি পুনরুদ্ধার করতে হতে পারে।
- একটি পোস্টপ্রসেসিং জাভাস্ক্রিপ্ট নীতি ব্যবহার করুন ম্যানুয়ালি কোনো কাস্টম বৈশিষ্ট্য যা আপনি প্রতিক্রিয়া দেখতে চান না বের করতে.
এছাড়াও টোকেন এবং অনুমোদন কোড কাস্টমাইজ করা দেখুন।
ডিফল্ট: | |
উপস্থিতি: | ঐচ্ছিক |
বৈধ মান: |
|
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<ClientId> উপাদান
<ClientId>request.formparam.client_id</ClientId>
বেশ কিছু ক্ষেত্রে, ক্লায়েন্ট অ্যাপকে অবশ্যই অনুমোদন সার্ভারে ক্লায়েন্ট আইডি পাঠাতে হবে। এই উপাদানটি নির্দিষ্ট করে যে Apigee কে ফ্লো ভেরিয়েবল request.formparam.client_id
এ ক্লায়েন্ট আইডি খোঁজা উচিত। অন্য কোনো ভেরিয়েবলে ClientId
সেট করা সমর্থিত নয়। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.
ডিফল্ট: | request.formparam.client_id (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে) |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | প্রবাহ পরিবর্তনশীল: request.formparam.client_id |
অনুদান প্রকারের সাথে ব্যবহৃত: |
GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহার করা যেতে পারে। |
<কোড> উপাদান
<Code>request.queryparam.code</Code>
অনুমোদনের অনুদানের প্রকারের প্রবাহে, ক্লায়েন্টকে অবশ্যই অনুমোদন সার্ভারে (Apigee Edge) একটি অনুমোদন কোড জমা দিতে হবে। এই উপাদানটি আপনাকে নির্দিষ্ট করতে দেয় যে প্রান্তের অনুমোদন কোডটি কোথায় দেখা উচিত। উদাহরণস্বরূপ, এটি একটি ক্যোয়ারী প্যারামিটার, HTTP হেডার, বা ফর্ম প্যারামিটার (ডিফল্ট) হিসাবে পাঠানো যেতে পারে।
ভেরিয়েবল, request.queryparam.auth_code
ইঙ্গিত করে যে অনুমোদন কোডটি একটি কোয়েরি প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, উদাহরণস্বরূপ, ?auth_code=AfGlvs9
। একটি HTTP শিরোনামে অনুমোদন কোড প্রয়োজন, উদাহরণস্বরূপ, এই মানটি request.header.auth_code
এ সেট করুন। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.
ডিফল্ট: | request.formparam.code (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে) |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোনো ফ্লো ভেরিয়েবল |
অনুদান প্রকারের সাথে ব্যবহৃত: | অনুমোদন_কোড |
<ExpiresIn> উপাদান
<ExpiresIn>10000</ExpiresIn>
মিলিসেকেন্ডে অ্যাক্সেস টোকেন এবং অনুমোদন কোডের মেয়াদ শেষ হওয়ার সময় বলবৎ করে। (রিফ্রেশ টোকেনগুলির জন্য, <RefreshTokenExpiresIn>
ব্যবহার করুন।) মেয়াদ শেষ হওয়ার সময় মান হল একটি সিস্টেম-উত্পন্ন মান এবং <ExpiresIn>
মান। যদি <ExpiresIn>
-1 তে সেট করা থাকে, তাহলে টোকেন বা কোডের মেয়াদ শেষ হয়ে যাবে সর্বোচ্চ OAuth অ্যাক্সেস টোকেনের মেয়াদ শেষ হবে । <ExpiresIn>
নির্দিষ্ট না হলে, সিস্টেমটি সিস্টেম স্তরে কনফিগার করা একটি ডিফল্ট মান প্রয়োগ করে।
হার্ড-কোডেড, ডিফল্ট মান ব্যবহার করে বা একটি ফ্লো ভেরিয়েবল উল্লেখ করে রানটাইমে মেয়াদ শেষ হওয়ার সময়ও সেট করা যেতে পারে। উদাহরণস্বরূপ, আপনি একটি মূল মান মানচিত্রে একটি টোকেন মেয়াদ শেষ হওয়ার মান সংরক্ষণ করতে পারেন, এটি পুনরুদ্ধার করতে পারেন, এটি একটি ভেরিয়েবলে বরাদ্দ করতে পারেন এবং নীতিতে এটি উল্লেখ করতে পারেন। উদাহরণস্বরূপ, kvm.oauth.expires_in
।
পাবলিক ক্লাউডের জন্য Apigee Edge- এর সাথে, Edge নিম্নলিখিত সত্তাগুলিকে ন্যূনতম 180 সেকেন্ডের জন্য ক্যাশে রাখে।
- OAuth অ্যাক্সেস টোকেন। এর অর্থ হল একটি প্রত্যাহার করা টোকেন এখনও তিন মিনিট পর্যন্ত সফল হতে পারে, যতক্ষণ না এটির ক্যাশে সীমা মেয়াদ শেষ হয়।
- কী ম্যানেজমেন্ট সার্ভিস (KMS) সত্তা (অ্যাপ, ডেভেলপার, API পণ্য)।
- OAuth টোকেন এবং KMS সত্তাগুলিতে কাস্টম বৈশিষ্ট্য।
নিম্নলিখিত স্তবকটি একটি ফ্লো ভেরিয়েবল এবং একটি ডিফল্ট মানও নির্দিষ্ট করে। উল্লেখ্য যে ফ্লো ভেরিয়েবল মান নির্দিষ্ট ডিফল্ট মানের চেয়ে অগ্রাধিকার নেয়।
<ExpiresIn ref="kvm.oauth.expires_in"> 3600000 <!--default value in milliseconds--> </ExpiresIn>
এজ একটি টোকেন তৈরি হওয়ার পরে তার মেয়াদ শেষ করতে বাধ্য করার উপায় সমর্থন করে না। আপনি যদি টোকেন মেয়াদ শেষ করতে বাধ্য করতে চান (উদাহরণস্বরূপ, একটি শর্তের উপর ভিত্তি করে), একটি সম্ভাব্য সমাধান এই Apigee কমিউনিটি পোস্টে বর্ণনা করা হয়েছে।
ডিফল্টরূপে, মেয়াদোত্তীর্ণ অ্যাক্সেস টোকেনগুলি মেয়াদ শেষ হওয়ার 3 দিন পরে স্বয়ংক্রিয়ভাবে Apigee Edge সিস্টেম থেকে পরিস্কার করা হয়। আরও দেখুন পার্জিং অ্যাক্সেস টোকেন
ব্যক্তিগত ক্লাউড: ব্যক্তিগত ক্লাউড ইনস্টলেশনের জন্য একটি প্রান্তের জন্য, ডিফল্ট মানটি conf_keymanagement_oauth_auth_code_expiry_time_in_millis
বৈশিষ্ট্য দ্বারা সেট করা হয়। এই সম্পত্তি সেট করতে:
- একটি এডিটরে
message-processor.properties
ফাইলটি খুলুন। ফাইলটি বিদ্যমান না থাকলে, এটি তৈরি করুন:vi /opt/apigee/customer/application/message-processor.properties
- পছন্দ অনুযায়ী সম্পত্তি সেট করুন:
conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000
- নিশ্চিত করুন যে বৈশিষ্ট্য ফাইলটি "apigee" ব্যবহারকারীর মালিকানাধীন:
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- মেসেজ প্রসেসর রিস্টার্ট করুন।
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
ডিফল্ট: | নির্দিষ্ট করা না থাকলে, সিস্টেমটি সিস্টেম স্তরে কনফিগার করা একটি ডিফল্ট মান প্রয়োগ করে। |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | পূর্ণসংখ্যা |
বৈধ মান: |
|
অনুদান প্রকারের সাথে ব্যবহৃত: |
এছাড়াও GenerateAuthorizationCode অপারেশনের সাথে ব্যবহৃত হয়। |
<ExternalAccessToken> উপাদান
<ExternalAccessToken>request.queryparam.external_access_token</ExternalAccessToken>
Apigee Edge কে একটি বাহ্যিক অ্যাক্সেস টোকেন কোথায় পেতে হবে তা বলে (একটি অ্যাক্সেস টোকেন Apigee Edge দ্বারা তৈরি করা হয়নি)।
ভেরিয়েবল request.queryparam.external_access_token
নির্দেশ করে যে এক্সটার্নাল অ্যাক্সেস টোকেন একটি কোয়েরি প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, উদাহরণস্বরূপ, ?external_access_token=12345678
। একটি HTTP শিরোনামে বহিরাগত অ্যাক্সেস টোকেন প্রয়োজন, উদাহরণস্বরূপ, এই মানটি request.header.external_access_token
এ সেট করুন। এছাড়াও তৃতীয় পক্ষের OAuth টোকেন ব্যবহার করা দেখুন।
<বাহ্যিক অনুমোদন> উপাদান
<ExternalAuthorization>true</ExternalAuthorization>
যদি এই উপাদানটি মিথ্যা হয় বা উপস্থিত না থাকে, তাহলে এজ সাধারণত Apigee এজ অনুমোদন স্টোরের বিরুদ্ধে ক্লায়েন্ট_আইডি এবং ক্লায়েন্ট_সিক্রেট যাচাই করে। আপনি যখন তৃতীয় পক্ষের OAuth টোকেনগুলির সাথে কাজ করতে চান তখন এই উপাদানটি ব্যবহার করুন৷ এই উপাদানটি ব্যবহার করার বিষয়ে বিস্তারিত জানার জন্য, তৃতীয় পক্ষের OAuth টোকেন ব্যবহার করা দেখুন।
ডিফল্ট: | মিথ্যা |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | বুলিয়ান |
বৈধ মান: | সত্য বা মিথ্যা |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<ExternalAuthorizationCode> উপাদান
<ExternalAuthorizationCode>request.queryparam.external_auth_code</ExternalAuthorizationCode>
Apigee Edge কে একটি বাহ্যিক প্রমাণীকরণ কোড কোথায় পাওয়া যাবে তা বলে (একটি প্রমাণীকরণ কোড Apigee Edge দ্বারা তৈরি করা হয়নি)।
ভেরিয়েবল request.queryparam.external_auth_code
নির্দেশ করে যে বহিরাগত প্রমাণীকরণ কোড একটি কোয়েরি প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, উদাহরণস্বরূপ, ?external_auth_code=12345678
। একটি HTTP হেডারে বাহ্যিক প্রমাণীকরণ কোডের প্রয়োজন করতে, উদাহরণস্বরূপ, এই মানটি request.header.external_auth_code
এ সেট করুন। এছাড়াও তৃতীয় পক্ষের OAuth টোকেন ব্যবহার করা দেখুন।
<ExternalRefreshToken> উপাদান
<ExternalRefreshToken>request.queryparam.external_refresh_token</ExternalRefreshToken>
Apigee Edge কে একটি বাহ্যিক রিফ্রেশ টোকেন কোথায় পাওয়া যাবে তা বলে (একটি রিফ্রেশ টোকেন Apigee Edge দ্বারা তৈরি করা হয়নি)।
ভেরিয়েবল request.queryparam.external_refresh_token
নির্দেশ করে যে এক্সটার্নাল রিফ্রেশ টোকেন একটি কোয়েরি প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, উদাহরণস্বরূপ, ?external_refresh_token=12345678
। একটি HTTP শিরোনামে বহিরাগত রিফ্রেশ টোকেন প্রয়োজন, উদাহরণস্বরূপ, এই মানটি request.header.external_refresh_token
এ সেট করুন। এছাড়াও তৃতীয় পক্ষের OAuth টোকেন ব্যবহার করা দেখুন।
<জেনারেট রেসপন্স> উপাদান
<GenerateResponse enabled='true'/>
true
সেট করা হলে, নীতিটি একটি প্রতিক্রিয়া তৈরি করে এবং ফেরত দেয়। উদাহরণস্বরূপ, GenerateAccessToken এর জন্য, প্রতিক্রিয়াটি এরকম হতে পারে:
{ "issued_at" : "1467841035013", "scope" : "read", "application_name" : "e31b8d06-d538-4f6b-9fe3-8796c11dc930", "refresh_token_issued_at" : "1467841035013", "status" : "approved", "refresh_token_status" : "approved", "api_product_list" : "[Product1, nhl_product]", "expires_in" : "1799", "developer.email" : "edward@slalom.org", "token_type" : "BearerToken", "refresh_token" : "rVSmm3QaNa0xBVFbUISz1NZI15akvgLJ", "client_id" : "Adfsdvoc7KX5Gezz9le745UEql5dDmj", "access_token" : "AnoHsh2oZ6EFWF4h0KrA0gC5og3a", "organization_name" : "cerruti", "refresh_token_expires_in" : "0", "refresh_count" : "0" }
false
হলে, কোন প্রতিক্রিয়া পাঠানো হয় না. পরিবর্তে, ফ্লো ভেরিয়েবলের একটি সেট পলিসির ফাংশনের সাথে সম্পর্কিত মানগুলির সাথে পপুলেট করা হয়। উদাহরণ স্বরূপ, oauthv2authcode.OAuthV2-GenerateAuthorizationCode.code
নামে একটি ফ্লো ভেরিয়েবল নতুন মিন্ট করা প্রমাণীকরণ কোডের সাথে পপুলেট হয়ে যায়। মনে রাখবেন যে expires_in প্রতিক্রিয়াতে সেকেন্ডে প্রকাশ করা হয়েছে।
ডিফল্ট: | মিথ্যা |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | সত্য বা মিথ্যা |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<GenerateErrorResponse> উপাদান
<GenerateErrorResponse enabled='true'/>
যদি true
তে সেট করা হয়, তাহলে ContinueOnError অ্যাট্রিবিউট সত্যে সেট করা থাকলে নীতিটি একটি প্রতিক্রিয়া তৈরি করে এবং ফেরত দেয়। false
হলে (ডিফল্ট), কোনো প্রতিক্রিয়া পাঠানো হয় না। পরিবর্তে, ফ্লো ভেরিয়েবলের একটি সেট পলিসির ফাংশনের সাথে সম্পর্কিত মানগুলির সাথে পপুলেট করা হয়।
ডিফল্ট: | মিথ্যা |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | সত্য বা মিথ্যা |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<গ্রান্ট টাইপ>
<GrantType>request.queryparam.grant_type</GrantType>
একটি অনুরোধে পাস করা অনুদানের প্রকারের প্যারামিটারটি কোথায় পাওয়া যাবে তা নীতিকে বলে৷ OAuth 2.0 স্পেসিফিকেশন অনুযায়ী, অনুদানের ধরন অবশ্যই অ্যাক্সেস টোকেন এবং অনুমোদন কোডের জন্য অনুরোধের সাথে সরবরাহ করতে হবে। ভেরিয়েবল একটি হেডার, ক্যোয়ারী প্যারামিটার বা ফর্ম প্যারামিটার (ডিফল্ট) হতে পারে।
উদাহরণস্বরূপ, request.queryparam.grant_type
নির্দেশ করে যে পাসওয়ার্ডটি একটি ক্যোয়ারী প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, উদাহরণস্বরূপ, ?grant_type=password
। একটি HTTP হেডারে অনুদানের প্রকারের প্রয়োজন করতে, উদাহরণস্বরূপ, এই মানটি request.header.grant_type
এ সেট করুন। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.
ডিফল্ট: | request.formparam.grant_type (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে) |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | একটি পরিবর্তনশীল, যেমন উপরে ব্যাখ্যা করা হয়েছে। |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<অপারেশন> উপাদান
<Operation>GenerateAuthorizationCode</Operation>
OAuth 2.0 অপারেশন নীতি দ্বারা সম্পাদিত।
ডিফল্ট: | যদি |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: |
|
<পাসওয়ার্ড> উপাদান
<PassWord>request.queryparam.password</PassWord>
এই উপাদানটি শুধুমাত্র পাসওয়ার্ড অনুদান প্রকারের সাথে ব্যবহার করা হয় । পাসওয়ার্ড অনুদানের প্রকারের সাথে, ব্যবহারকারীর শংসাপত্র (পাসওয়ার্ড এবং ব্যবহারকারীর নাম) অবশ্যই OAuthV2 নীতিতে উপলব্ধ করা উচিত। <PassWord>
এবং <UserName>
উপাদানগুলি ভেরিয়েবলগুলি নির্দিষ্ট করতে ব্যবহৃত হয় যেখানে এজ এই মানগুলি খুঁজে পেতে পারে। যদি এই উপাদানগুলি নির্দিষ্ট করা না থাকে, নীতিটি username
এবং password
নামের ফর্ম প্যারামিটারগুলিতে মানগুলি (ডিফল্টরূপে) খুঁজে পাওয়ার আশা করে৷ মান পাওয়া না গেলে, নীতি একটি ত্রুটি নিক্ষেপ করে। আপনি <PassWord>
এবং <UserName>
উপাদানগুলি ব্যবহার করতে পারেন শংসাপত্র সমেত যেকোনো ফ্লো ভেরিয়েবল উল্লেখ করতে।
উদাহরণস্বরূপ, আপনি একটি ক্যোয়ারী প্যারামিটার ব্যবহার করে একটি টোকেন অনুরোধে পাসওয়ার্ডটি পাস করতে পারেন এবং এইভাবে উপাদান সেট করতে পারেন: <PassWord>request.queryparam.password</PassWord>
.
একটি HTTP হেডারে পাসওয়ার্ডের প্রয়োজন করতে, এই মানটি request.header.password
এ সেট করুন।
OAuthV2 নীতি এই শংসাপত্রের মানগুলির সাথে অন্য কিছু করে না; এজ কেবল যাচাই করছে যে তারা উপস্থিত রয়েছে। মান অনুরোধ পুনরুদ্ধার করা এবং টোকেন জেনারেশন নীতি কার্যকর হওয়ার আগে একটি পরিচয় প্রদানকারীর কাছে পাঠানোর বিষয়টি API বিকাশকারীর উপর নির্ভর করে।
এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.
ডিফল্ট: | request.formparam.password (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে) |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | রানটাইমে নীতিতে উপলব্ধ যেকোন প্রবাহ পরিবর্তনশীল। |
অনুদান প্রকারের সাথে ব্যবহৃত: | পাসওয়ার্ড |
<RedirectUri> উপাদান
<RedirectUri>request.queryparam.redirect_uri</RedirectUri>
অনুরোধে redirect_uri
প্যারামিটার কোথায় এজ দেখতে হবে তা নির্দিষ্ট করে।
পুনর্নির্দেশ URI সম্পর্কে
পুনঃনির্দেশ ইউআরআই অনুমোদন কোড এবং অন্তর্নিহিত অনুদান প্রকারের সাথে ব্যবহার করা হয়। রিডাইরেক্ট ইউআরআই অনুমোদন সার্ভারকে (এজ) বলে যে কোথায় একটি অনুমোদন কোড পাঠাতে হবে (প্রমাণ কোড অনুদান প্রকারের জন্য) বা অ্যাক্সেস টোকেন (অন্তর্ভুক্ত অনুদান প্রকারের জন্য)। এই প্যারামিটারটি কখন প্রয়োজন, কখন এটি ঐচ্ছিক এবং কীভাবে এটি ব্যবহার করা হয় তা বোঝা গুরুত্বপূর্ণ:
(প্রয়োজনীয়) যদি একটি কলব্যাক ইউআরএল ডেভেলপার অ্যাপের সাথে নিবন্ধিত হয় যা অনুরোধের ক্লায়েন্ট কীগুলির সাথে যুক্ত থাকে এবং যদি অনুরোধে
redirect_uri
উপস্থিত থাকে, তাহলে দুটি অবশ্যই মিলবে। যদি তারা মেলে না, একটি ত্রুটি ফিরে আসে। এজ-এ ডেভেলপার অ্যাপস নিবন্ধন এবং একটি কলব্যাক ইউআরএল নির্দিষ্ট করার তথ্যের জন্য, অ্যাপস নিবন্ধন করুন এবং API কীগুলি পরিচালনা করুন দেখুন।- (ঐচ্ছিক) যদি একটি কলব্যাক URL নিবন্ধিত হয়, এবং অনুরোধ থেকে
redirect_uri
অনুপস্থিত থাকে, তাহলে এজ নিবন্ধিত কলব্যাক URL-এ পুনঃনির্দেশ করে। - (প্রয়োজনীয়) যদি একটি কলব্যাক URL নিবন্ধিত না হয়, তাহলে
redirect_uri
প্রয়োজন। মনে রাখবেন যে এই ক্ষেত্রে, এজ যেকোনো URL গ্রহণ করবে। এই ক্ষেত্রে একটি নিরাপত্তা সমস্যা উপস্থাপন করতে পারে, এবং তাই শুধুমাত্র বিশ্বস্ত ক্লায়েন্ট অ্যাপের সাথে ব্যবহার করা উচিত। যদি ক্লায়েন্ট অ্যাপ্লিকেশানগুলি বিশ্বস্ত না হয়, তাহলে সর্বোত্তম অনুশীলন হল সর্বদা একটি কলব্যাক URL-এর নিবন্ধন প্রয়োজন৷
আপনি এই প্যারামিটারটি একটি ক্যোয়ারী প্যারামিটারে বা হেডারে পাঠাতে পারেন। ভেরিয়েবল request.queryparam.redirect_uri
নির্দেশ করে যে RedirectUri একটি ক্যোয়ারী প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, ?redirect_uri=login.myapp.com
। একটি HTTP হেডারে RedirectUri প্রয়োজনের জন্য, উদাহরণস্বরূপ, এই মানটি request.header.redirect_uri
তে সেট করুন। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.
ডিফল্ট: | request.formparam.redirect_uri (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে) |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোন প্রবাহ পরিবর্তনশীল |
অনুদান প্রকারের সাথে ব্যবহৃত: |
GenerateAuthorizationCode অপারেশনের সাথেও ব্যবহৃত হয়। |
<রিফ্রেশটোকেন> উপাদান
<RefreshToken>request.queryparam.refreshtoken</RefreshToken>
রিফ্রেশ টোকেন ব্যবহার করে একটি অ্যাক্সেস টোকেন অনুরোধ করার সময়, আপনাকে অনুরোধে রিফ্রেশ টোকেন সরবরাহ করতে হবে। এই উপাদানটি আপনাকে নির্দিষ্ট করতে দেয় যে প্রান্তটি রিফ্রেশ টোকেনের জন্য কোথায় সন্ধান করবে৷ উদাহরণস্বরূপ, এটি একটি ক্যোয়ারী প্যারামিটার, HTTP হেডার, বা ফর্ম প্যারামিটার (ডিফল্ট) হিসাবে পাঠানো যেতে পারে।
ভেরিয়েবল request.queryparam.refreshtoken
ইঙ্গিত করে যে রিফ্রেশ টোকেন একটি ক্যোয়ারী প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, উদাহরণস্বরূপ, ?refresh_token=login.myapp.com
। একটি HTTP হেডারে RefreshToken প্রয়োজনের জন্য, উদাহরণস্বরূপ, এই মানটি request.header.refresh_token
এ সেট করুন। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.
ডিফল্ট: | request.formparam.refresh_token (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে) |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোন প্রবাহ পরিবর্তনশীল |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<RefreshTokenExpiresIn> উপাদান
<RefreshTokenExpiresIn>1000</RefreshTokenExpiresIn>
মিলিসেকেন্ডে রিফ্রেশ টোকেনের মেয়াদ শেষ হওয়ার সময় বলবৎ করে। মেয়াদ শেষ হওয়ার সময় মান হল একটি সিস্টেম জেনারেটেড মান এবং <RefreshTokenExpiresIn>
মান। যদি <RefreshTokenExpiresIn>
সেট করা থাকে -1 , সর্বোচ্চ OAuth রিফ্রেশ টোকেনের মেয়াদ শেষ হয়ে যায়। <RefreshTokenExpiresIn>
নির্দিষ্ট করা না থাকলে, সিস্টেমটি সিস্টেম স্তরে কনফিগার করা একটি ডিফল্ট মান প্রয়োগ করে। ডিফল্ট সিস্টেম সেটিংস সম্পর্কে আরও তথ্যের জন্য Apigee Edge সমর্থনের সাথে যোগাযোগ করুন।
হার্ড-কোডেড, ডিফল্ট মান ব্যবহার করে বা একটি ফ্লো ভেরিয়েবল উল্লেখ করে রানটাইমে মেয়াদ শেষ হওয়ার সময়ও সেট করা যেতে পারে। উদাহরণস্বরূপ, আপনি একটি মূল মান মানচিত্রে একটি টোকেন মেয়াদ শেষ হওয়ার মান সংরক্ষণ করতে পারেন, এটি পুনরুদ্ধার করতে পারেন, এটি একটি ভেরিয়েবলে বরাদ্দ করতে পারেন এবং নীতিতে এটি উল্লেখ করতে পারেন। উদাহরণস্বরূপ, kvm.oauth.expires_in
।
নিম্নলিখিত স্তবকটি একটি ফ্লো ভেরিয়েবল এবং একটি ডিফল্ট মানও নির্দিষ্ট করে। উল্লেখ্য যে ফ্লো ভেরিয়েবল মান নির্দিষ্ট ডিফল্ট মানের চেয়ে অগ্রাধিকার নেয়।
<RefreshTokenExpiresIn ref="kvm.oauth.expires_in"> 3600000 <!--default value in milliseconds--> </RefreshTokenExpiresIn>
ব্যক্তিগত ক্লাউড: ব্যক্তিগত ক্লাউড ইনস্টলেশনের জন্য একটি প্রান্তের জন্য, ডিফল্ট মানটি conf_keymanagement_oauth_refresh_token_expiry_time_in_millis
বৈশিষ্ট্য দ্বারা সেট করা হয়। এই সম্পত্তি সেট করতে:
- একটি এডিটরে
message-processor.properties
ফাইলটি খুলুন। ফাইলটি বিদ্যমান না থাকলে, এটি তৈরি করুন:vi /opt/apigee/customer/application/message-processor.properties
- পছন্দ অনুযায়ী সম্পত্তি সেট করুন:
conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000
- নিশ্চিত করুন যে বৈশিষ্ট্য ফাইলটি "apigee" ব্যবহারকারীর মালিকানাধীন:
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- মেসেজ প্রসেসর রিস্টার্ট করুন।
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
ডিফল্ট: | 63072000000 ms (2 বছর) (কার্যকর 05 আগস্ট, 2024) |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | পূর্ণসংখ্যা |
বৈধ মান: |
|
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<ResponseType> উপাদান
<ResponseType>request.queryparam.response_type</ResponseType>
এই উপাদানটি এজকে জানায় যে ক্লায়েন্ট অ্যাপটি কোন ধরনের অনুদান অনুরোধ করছে। এটি শুধুমাত্র অনুমোদন কোড এবং অন্তর্নিহিত অনুদান প্রকার প্রবাহের সাথে ব্যবহার করা হয়।
ডিফল্টরূপে, এজ response_type
ক্যোয়ারী প্যারামিটারে রেসপন্স টাইপ মান খোঁজে। আপনি যদি এই ডিফল্ট আচরণকে ওভাররাইড করতে চান, তাহলে প্রতিক্রিয়া প্রকার মান সহ একটি ফ্লো ভেরিয়েবল কনফিগার করতে <ResponseType> উপাদানটি ব্যবহার করুন। উদাহরণস্বরূপ, আপনি যদি এই উপাদানটি request.header.response_type
এ সেট করেন, তাহলে এজ অনুরোধের শিরোনামে পাস করা প্রতিক্রিয়ার ধরনটি সন্ধান করে। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.
ডিফল্ট: | request.formparam.response_type (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে) |
উপস্থিতি: | ঐচ্ছিক। আপনি যদি ডিফল্ট আচরণ ওভাররাইড করতে চান তাহলে এই উপাদানটি ব্যবহার করুন। |
প্রকার: | স্ট্রিং |
বৈধ মান: | হয় code (অনুমোদন কোড অনুদান প্রকারের জন্য) বা token (অন্তর্ভুক্ত অনুদান প্রকারের জন্য) |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<ReuseRefreshToken> উপাদান
<ReuseRefreshToken>true</ReuseRefreshToken>
true
সেট করা হলে, বিদ্যমান রিফ্রেশ টোকেনটি মেয়াদ শেষ না হওয়া পর্যন্ত পুনরায় ব্যবহার করা হয়। false
হলে, একটি বৈধ রিফ্রেশ টোকেন উপস্থাপিত হলে Apigee Edge দ্বারা একটি নতুন রিফ্রেশ টোকেন জারি করা হয়।
ডিফল্ট: | |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | বুলিয়ান |
বৈধ মান: | |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<স্কোপ> উপাদান
<Scope>request.queryparam.scope</Scope>
যদি এই উপাদানটি GenerateAccessToken বা GenerateAuthorizationCode নীতিগুলির মধ্যে একটিতে উপস্থিত থাকে, তাহলে টোকেন বা কোড মঞ্জুর করার সুযোগগুলি নির্দিষ্ট করতে এটি ব্যবহার করা হয়। এই মানগুলি সাধারণত একটি ক্লায়েন্ট অ্যাপের অনুরোধে নীতিতে পাঠানো হয়। আপনি একটি ফ্লো ভেরিয়েবল নেওয়ার জন্য উপাদানটি কনফিগার করতে পারেন, আপনাকে একটি অনুরোধে কীভাবে স্কোপগুলি পাস করা হয় তা চয়ন করার বিকল্প দেয়৷ নিম্নলিখিত উদাহরণে, request.queryparam.scope
নির্দেশ করে যে স্কোপটি একটি কোয়েরি প্যারামিটার হিসাবে উপস্থিত হওয়া উচিত, যেমন, উদাহরণস্বরূপ, ?scope=READ
। একটি HTTP হেডারে সুযোগের প্রয়োজনের জন্য, উদাহরণস্বরূপ, এই মানটি request.header.scope
এ সেট করুন।
যদি এই উপাদানটি একটি "VerifyAccessToken" নীতিতে উপস্থিত হয়, তাহলে নীতিটি প্রয়োগ করা উচিত কোন স্কোপগুলি নির্দিষ্ট করতে এটি ব্যবহার করা হয়৷ এই ধরনের নীতিতে, মান অবশ্যই একটি "হার্ড কোডেড" স্কোপের নাম হতে হবে -- আপনি ভেরিয়েবল ব্যবহার করতে পারবেন না। যেমন:
<Scope>A B</Scope>
এছাড়াও OAuth2 স্কোপের সাথে কাজ করা এবং অ্যাক্সেস টোকেন এবং অনুমোদন কোডের অনুরোধ করা দেখুন।
ডিফল্ট: | সুযোগ নেই |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | যদি জেনারেট* নীতির সাথে ব্যবহার করা হয়, একটি প্রবাহ পরিবর্তনশীল। যদি VerifyAccessToken এর সাথে ব্যবহার করা হয়, তাহলে স্কোপের নামের (স্ট্রিং) একটি স্থান-বিচ্ছিন্ন তালিকা। |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<State> উপাদান
<State>request.queryparam.state</State>
যে ক্ষেত্রে ক্লায়েন্ট অ্যাপকে অবশ্যই রাষ্ট্রীয় তথ্য অনুমোদন সার্ভারে পাঠাতে হবে, এই উপাদানটি আপনাকে নির্দিষ্ট করতে দেয় যে এজ রাষ্ট্রীয় মানগুলির জন্য কোথায় সন্ধান করবে। উদাহরণস্বরূপ, এটি একটি ক্যোয়ারী প্যারামিটার হিসাবে বা একটি HTTP শিরোনামে পাঠানো যেতে পারে। রাষ্ট্রীয় মান সাধারণত CSRF আক্রমণ প্রতিরোধ করার জন্য একটি নিরাপত্তা ব্যবস্থা হিসাবে ব্যবহৃত হয়।
উদাহরণস্বরূপ, request.queryparam.state
নির্দেশ করে যে রাজ্যটি একটি ক্যোয়ারী প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, উদাহরণস্বরূপ, ?state=HjoiuKJH32
। একটি HTTP হেডারে রাজ্যের প্রয়োজনের জন্য, উদাহরণস্বরূপ, এই মানটি request.header.state
এ সেট করুন। আরও দেখুন অ্যাক্সেস টোকেন এবং অনুমোদন কোডের অনুরোধ করাও দেখুন।
ডিফল্ট: | রাষ্ট্র নেই |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | রানটাইমে নীতিতে অ্যাক্সেসযোগ্য যেকোনো ফ্লো ভেরিয়েবল |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<StoreToken> উপাদান
<StoreToken>true</StoreToken>
<ExternalAuthorization>
উপাদানটি true
হলে এই উপাদানটিকে true
হিসাবে সেট করুন। <StoreToken>
উপাদান Apigee এজকে বাহ্যিক অ্যাক্সেস টোকেন সংরক্ষণ করতে বলে। অন্যথায়, এটি অব্যাহত থাকবে না।
ডিফল্ট: | মিথ্যা |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | বুলিয়ান |
বৈধ মান: | সত্য বা মিথ্যা |
অনুদান প্রকারের সাথে ব্যবহৃত: |
|
<সমর্থিত গ্রান্ট টাইপ>/<গ্রান্ট টাইপ> উপাদান
<SupportedGrantTypes> <GrantType>authorization_code</GrantType> <GrantType>client_credentials</GrantType> <GrantType>implicit</GrantType> <GrantType>password</GrantType> </SupportedGrantTypes>
Apigee Edge-এ OAuth টোকেন এন্ডপয়েন্ট দ্বারা সমর্থিত অনুদানের প্রকারগুলি নির্দিষ্ট করে৷ একটি এন্ডপয়েন্ট একাধিক অনুদান প্রকারকে সমর্থন করতে পারে (অর্থাৎ, একাধিক অনুদান প্রকারের জন্য অ্যাক্সেস টোকেন বিতরণ করার জন্য একটি একক এন্ডপয়েন্ট কনফিগার করা যেতে পারে।) এন্ডপয়েন্ট সম্পর্কে আরও জানতে, OAuth এন্ডপয়েন্ট বোঝার বিষয়টি দেখুন। অনুদানের ধরনটি একটি grant_type
প্যারামিটারে টোকেন অনুরোধে পাস করা হয়।
যদি কোনো সমর্থিত অনুদানের ধরন নির্দিষ্ট করা না থাকে, তাহলে শুধুমাত্র অনুমোদিত অনুদান প্রকারগুলি হল authorization_code
এবং implicit
। এছাড়াও <GrantType> উপাদানটি দেখুন (যা একটি উচ্চ-স্তরের উপাদান যা নির্দিষ্ট করতে ব্যবহৃত হয় যেখানে Apigee Edge grant_type
প্যারামিটারের সন্ধান করবে যা একটি ক্লায়েন্ট অনুরোধে পাস করা হয়। এজ নিশ্চিত করবে যে grant_type
প্যারামিটারের মান একটির সাথে মিলে যায়। সমর্থিত অনুদান প্রকার)।
ডিফল্ট: | অনুমোদন _কোড এবং অন্তর্নিহিত |
উপস্থিতি: | প্রয়োজন |
প্রকার: | স্ট্রিং |
বৈধ মান: |
|
<টোকেন>/<টোকেন> উপাদান
ValidateToken এবং InvalidateToken অপারেশনের সাথে ব্যবহার করা হয়। অ্যাক্সেস টোকেন অনুমোদন করা এবং প্রত্যাহার করাও দেখুন। <টোকেন> উপাদানটি ফ্লো ভেরিয়েবলকে চিহ্নিত করে যা প্রত্যাহার করা টোকেনের উৎসকে সংজ্ঞায়িত করে। যদি বিকাশকারীরা access_token
নামের কোয়েরি প্যারামিটার হিসাবে অ্যাক্সেস টোকেন জমা দেওয়ার আশা করা হয়, উদাহরণস্বরূপ, request.queryparam.access_token
ব্যবহার করুন।
<ব্যবহারকারীর নাম> উপাদান
<UserName>request.queryparam.user_name</UserName>
এই উপাদানটি শুধুমাত্র পাসওয়ার্ড অনুদান প্রকারের সাথে ব্যবহার করা হয় । পাসওয়ার্ড অনুদানের প্রকারের সাথে, ব্যবহারকারীর শংসাপত্র (পাসওয়ার্ড এবং ব্যবহারকারীর নাম) অবশ্যই OAuthV2 নীতিতে উপলব্ধ করা উচিত। <PassWord>
এবং <UserName>
উপাদানগুলি ভেরিয়েবলগুলি নির্দিষ্ট করতে ব্যবহৃত হয় যেখানে এজ এই মানগুলি খুঁজে পেতে পারে। যদি এই উপাদানগুলি নির্দিষ্ট করা না থাকে, নীতিটি username
এবং password
নামের ফর্ম প্যারামিটারগুলিতে মানগুলি (ডিফল্টরূপে) খুঁজে পাওয়ার আশা করে৷ মান পাওয়া না গেলে, নীতি একটি ত্রুটি নিক্ষেপ করে। আপনি <PassWord>
এবং <UserName>
উপাদানগুলি ব্যবহার করতে পারেন শংসাপত্র সমেত যেকোনো ফ্লো ভেরিয়েবল উল্লেখ করতে।
উদাহরণস্বরূপ, আপনি একটি ক্যোয়ারী প্যারামিটারে ব্যবহারকারীর নামটি পাস করতে পারেন এবং এইভাবে <UserName>
উপাদান সেট করতে পারেন: <UserName>request.queryparam.username</UserName>
.
একটি HTTP হেডারে ব্যবহারকারীর নাম প্রয়োজন করতে, এই মানটি request.header.username
এ সেট করুন।
OAuthV2 নীতি এই শংসাপত্রের মানগুলির সাথে অন্য কিছু করে না; এজ কেবল যাচাই করছে যে তারা উপস্থিত রয়েছে। মান অনুরোধ পুনরুদ্ধার করা এবং টোকেন জেনারেশন নীতি কার্যকর হওয়ার আগে একটি পরিচয় প্রদানকারীর কাছে পাঠানোর বিষয়টি API বিকাশকারীর উপর নির্ভর করে।
এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.
ডিফল্ট: | request.formparam.username (একটি x-www-form-urlencoded এবং অনুরোধের বডিতে উল্লেখ করা হয়েছে) |
উপস্থিতি: | ঐচ্ছিক |
প্রকার: | স্ট্রিং |
বৈধ মান: | যেকোনো পরিবর্তনশীল সেটিং। |
অনুদান প্রকারের সাথে ব্যবহৃত: | পাসওয়ার্ড |
অ্যাক্সেস টোকেন যাচাই করা
একবার একটি এপিআই প্রক্সি জন্য একটি টোকেন এন্ডপয়েন্ট সেট আপ করা হলে, একটি সংশ্লিষ্ট OAUTHV2 নীতি যা VerifyAccessToken
অপারেশনটি নির্দিষ্ট করে যা সুরক্ষিত সংস্থানটি প্রকাশ করে এমন প্রবাহের সাথে সংযুক্ত থাকে।
উদাহরণস্বরূপ, কোনও এপিআই -তে সমস্ত অনুরোধ অনুমোদিত তা নিশ্চিত করার জন্য, নিম্নলিখিত নীতিটি অ্যাক্সেস টোকেন যাচাইকরণ প্রয়োগ করে:
<OAuthV2 name="VerifyOAuthAccessToken"> <Operation>VerifyAccessToken</Operation> </OAuthV2>
নীতিটি সুরক্ষিত হওয়ার জন্য এপিআই রিসোর্সের সাথে সংযুক্ত রয়েছে। কোনও এপিআই -তে সমস্ত অনুরোধ যাচাই করা হয়েছে তা নিশ্চিত করার জন্য, প্রক্সিেন্ডপয়েন্টের অনুরোধ প্রিফ্লোতে নীতিটি সংযুক্ত করুন, নিম্নরূপ:
<PreFlow> <Request> <Step><Name>VerifyOAuthAccessToken</Name></Step> </Request> </PreFlow>
নিম্নলিখিত al চ্ছিক উপাদানগুলি যাচাইকরণ টোকেন অপারেশনের জন্য ডিফল্ট সেটিংসকে ওভাররাইড করতে ব্যবহার করা যেতে পারে।
নাম | বর্ণনা |
---|---|
ব্যাপ্তি | স্কোপগুলির একটি স্থান-ধ্বংসাত্মক তালিকা। তালিকাভুক্ত কমপক্ষে একটি স্কোপ অ্যাক্সেস টোকেনে উপস্থিত থাকলে যাচাইকরণ সফল হবে। উদাহরণস্বরূপ, নিম্নলিখিত নীতিটি এতে তালিকাভুক্ত স্কোপগুলির মধ্যে কমপক্ষে একটি রয়েছে তা নিশ্চিত করার জন্য অ্যাক্সেস টোকেনটি পরীক্ষা করবে। যদি পড়া বা লেখার উপস্থিতি থাকে তবে যাচাইকরণ সফল হবে। <OAuthV2 name="ValidateOauthScopePolicy"> <Operation>VerifyAccessToken</Operation> <Scope>READ WRITE</Scope> </OAuthV2> |
অ্যাক্সেস টোকেন | ভেরিয়েবল যেখানে অ্যাক্সেস টোকেনটি অবস্থিত হবে বলে আশা করা হচ্ছে। উদাহরণস্বরূপ request.queryparam.accesstoken । ডিফল্টরূপে, অ্যাক্সেস টোকেনটি অনুমোদনের এইচটিটিপি শিরোনামে অ্যাপ্লিকেশন দ্বারা উপস্থাপন করা হবে বলে আশা করা হচ্ছে, ওএউথ ২.০ স্পেসিফিকেশন অনুসারে। অ্যাক্সেস টোকেনটি কোনও অ-মানক স্থানে যেমন কোয়েরি প্যারামিটার, বা অনুমোদন ব্যতীত অন্য কোনও নাম সহ এইচটিটিপি শিরোনামে উপস্থাপন করা হবে বলে আশা করা হচ্ছে তবে এই সেটিংটি ব্যবহার করুন। |
অ্যাক্সেস টোকেনগুলি যাচাই করা এবং অ্যাক্সেস টোকেন এবং অনুমোদনের কোডগুলির জন্য অনুরোধ করাও দেখুন।
অনুরোধ পরিবর্তনশীল অবস্থান নির্দিষ্ট করে
প্রতিটি অনুদানের ধরণের জন্য, নীতিটি অনুরোধ বার্তাগুলিতে অবস্থান বা প্রয়োজনীয় তথ্য সম্পর্কে অনুমান করে। এই অনুমানগুলি OAuth 2.0 স্পেসিফিকেশনের উপর ভিত্তি করে। যদি আপনার অ্যাপ্লিকেশনগুলিকে OAuth 2.0 স্পেসিফিকেশন থেকে বিচ্যুত করার প্রয়োজন হয় তবে আপনি প্রতিটি প্যারামিটারের জন্য প্রত্যাশিত অবস্থানগুলি নির্দিষ্ট করতে পারেন। উদাহরণস্বরূপ, কোনও অনুমোদনের কোড পরিচালনা করার সময়, আপনি অনুমোদনের কোড, ক্লায়েন্ট আইডি, পুনর্নির্দেশের ইউআরআই এবং সুযোগের অবস্থান নির্দিষ্ট করতে পারেন। এগুলি এইচটিটিপি শিরোনাম, ক্যোয়ারী পরামিতি বা ফর্ম পরামিতি হিসাবে নির্দিষ্ট করা যেতে পারে।
নীচের উদাহরণটি দেখায় যে আপনি কীভাবে প্রয়োজনীয় অনুমোদনের কোড পরামিতিগুলির অবস্থানটি এইচটিটিপি শিরোনাম হিসাবে নির্দিষ্ট করতে পারেন:
... <GrantType>request.header.grant_type</GrantType> <Code>request.header.code</Code> <ClientId>request.header.client_id</ClientId> <RedirectUri>request.header.redirect_uri</RedirectUri> <Scope>request.header.scope</Scope> ...
অথবা, যদি আপনার ক্লায়েন্ট অ্যাপ বেসকে সমর্থন করার জন্য প্রয়োজন হয় তবে আপনি শিরোনাম এবং ক্যোয়ারী পরামিতিগুলি মিশ্রিত করতে এবং মেলে:
... <GrantType>request.header.grant_type</GrantType> <Code>request.header.code</Code> <ClientId>request.queryparam.client_id</ClientId> <RedirectUri>request.queryparam.redirect_uri</RedirectUri> <Scope>request.queryparam.scope</Scope> ...
প্যারামিটার প্রতি কেবলমাত্র একটি অবস্থান কনফিগার করা যেতে পারে।
প্রবাহ ভেরিয়েবল
এই টেবিলটিতে সংজ্ঞায়িত প্রবাহের ভেরিয়েবলগুলি পপুলেশন করা হয় যখন সম্পর্কিত OAuth নীতিগুলি কার্যকর করা হয় এবং তাই এপিআই প্রক্সি প্রবাহে কার্যকর করা অন্যান্য নীতি বা অ্যাপ্লিকেশনগুলির জন্য উপলব্ধ।
যাচাই -অ্যাক্সেস টোকেন অপারেশন
যাচাই -অ্যাক্সেস টোকেন অপারেশন কার্যকর করে, প্রক্সির কার্যকরকরণের প্রসঙ্গে প্রচুর পরিমাণে প্রবাহের ভেরিয়েবলগুলি পপুলেট করা হয়। এই ভেরিয়েবলগুলি আপনাকে অ্যাক্সেস টোকেন, বিকাশকারী অ্যাপ্লিকেশন, বিকাশকারী এবং সংস্থা সম্পর্কিত বৈশিষ্ট্য দেয়। আপনি একটি অ্যাসাইনমেসেজ বা জাভাস্ক্রিপ্ট নীতি ব্যবহার করতে পারেন, উদাহরণস্বরূপ, এই ভেরিয়েবলগুলির যে কোনওটি পড়তে এবং প্রবাহের পরে প্রয়োজনীয় হিসাবে সেগুলি ব্যবহার করতে পারেন। এই ভেরিয়েবলগুলি ডিবাগিংয়ের উদ্দেশ্যেও কার্যকর হতে পারে।
proxy.pathsuffix
থেকে প্রাপ্ত) দিয়ে কনফিগার করা থাকে। স্পষ্টভাবে প্রবাহ সেট করা। যেখানে এপিআই পণ্যগুলি বৈধ পরিবেশ এবং এপিআই প্রক্সিগুলির সাথে কনফিগার করা হয় না, তারপরে flow.resource.name
অবশ্যই প্রবাহে এপিআই পণ্য ভেরিয়েবলগুলি জনপ্রিয় করতে সেট করতে হবে। পণ্য কনফিগারেশনের বিশদগুলির জন্য, এপিআই প্রকাশের জন্য এজ ম্যানেজমেন্ট এপিআই ব্যবহার করে দেখুন।
টোকেন-নির্দিষ্ট ভেরিয়েবল
ভেরিয়েবল | বর্ণনা |
---|---|
organization_name | প্রক্সি কার্যকর করছে এমন সংস্থার নাম। |
developer.id | নিবন্ধিত ক্লায়েন্ট অ্যাপের সাথে সম্পর্কিত বিকাশকারীর আইডি। |
developer.app.name | নিবন্ধিত ক্লায়েন্ট অ্যাপের সাথে সম্পর্কিত বিকাশকারীর নাম। |
client_id | নিবন্ধিত ক্লায়েন্ট অ্যাপের ক্লায়েন্ট আইডি। |
grant_type | অনুরোধের সাথে সম্পর্কিত অনুদানের ধরণ। |
token_type | অনুরোধের সাথে যুক্ত টোকেন টাইপ। |
access_token | অ্যাক্সেস টোকেন যা যাচাই করা হচ্ছে। |
accesstoken.{custom_attribute} | অ্যাক্সেস টোকনে একটি নামযুক্ত কাস্টম বৈশিষ্ট্য। |
issued_at | মিলিসেকেন্ডে ইউনিক্স এপোক টাইমে প্রকাশিত অ্যাক্সেস টোকেন জারি করা হয়েছিল। |
expires_in | অ্যাক্সেস টোকেনের মেয়াদ শেষ হওয়ার সময়। সেকেন্ডে প্রকাশ। যদিও ExpiresIn উপাদানটি টোকেন প্রতিক্রিয়া এবং প্রবাহের ভেরিয়েবলগুলিতে মিলিসেকেন্ডে মেয়াদোত্তীর্ণতা নির্ধারণ করে, মানটি কয়েক সেকেন্ডে এক্সপ্রেস করা হয়। |
status | অ্যাক্সেস টোকেনের স্থিতি (যেমন, অনুমোদিত বা প্রত্যাহার)। |
scope | অ্যাক্সেস টোকেনের সাথে সম্পর্কিত স্কোপ (যদি থাকে)। |
apiproduct.<custom_attribute_name> | নিবন্ধিত ক্লায়েন্ট অ্যাপের সাথে সম্পর্কিত এপিআই পণ্যের একটি নামযুক্ত কাস্টম বৈশিষ্ট্য। |
apiproduct.name | নিবন্ধিত ক্লায়েন্ট অ্যাপের সাথে সম্পর্কিত এপিআই পণ্যের নাম। |
revoke_reason | (কেবলমাত্র এপিগি হাইব্রিড) কেন অ্যাক্সেস টোকেন বাতিল করা হয় তা নির্দেশ করে। মান প্রত্যাহার করা |
অ্যাপ্লিকেশন-নির্দিষ্ট ভেরিয়েবল
এই ভেরিয়েবলগুলি টোকেনের সাথে সম্পর্কিত বিকাশকারী অ্যাপের সাথে সম্পর্কিত।
ভেরিয়েবল | বর্ণনা |
---|---|
app.name | |
app.id | |
app.accessType | |
app.callbackUrl | |
app.status | অনুমোদিত বা প্রত্যাহার |
app.scopes | |
app.appFamily | |
app.apiproducts | |
app.appParentStatus | |
app.appType | উদাহরণস্বরূপ: বিকাশকারী |
app.appParentId | |
app.created_by | |
app.created_at | |
app.last_modified_at | |
app.last_modified_by | |
app.{custom_attributes} | নিবন্ধিত ক্লায়েন্ট অ্যাপের একটি নামযুক্ত কাস্টম বৈশিষ্ট্য। |
বিকাশকারী-নির্দিষ্ট ভেরিয়েবল
যদি অ্যাপ.এপ টাইপটি "সংস্থা" হয়, তবে সংস্থার বৈশিষ্ট্যগুলি পপুলেটেড হয় এবং যদি অ্যাপ্লিকেশন.এপ টাইপ "বিকাশকারী" হয় তবে বিকাশকারী বৈশিষ্ট্যগুলি পপুলেটেড হয়।
ভেরিয়েবল | বর্ণনা |
---|---|
বিকাশকারী-নির্দিষ্ট ভেরিয়েবল | |
developer.id | |
developer.userName | |
developer.firstName | |
developer.lastName | |
developer.email | |
developer.status | সক্রিয় বা নিষ্ক্রিয় |
developer.apps | |
developer.created_by | |
developer.created_at | |
developer.last_modified_at | |
developer.last_modified_by | |
developer.{custom_attributes} | বিকাশকারীর একটি নামযুক্ত কাস্টম বৈশিষ্ট্য। |
সংস্থা-নির্দিষ্ট ভেরিয়েবল
যদি অ্যাপ.এপ টাইপটি "সংস্থা" হয়, তবে সংস্থার বৈশিষ্ট্যগুলি পপুলেটেড হয় এবং যদি অ্যাপ্লিকেশন.এপ টাইপ "বিকাশকারী" হয় তবে বিকাশকারী বৈশিষ্ট্যগুলি পপুলেটেড হয়।
ভেরিয়েবল | বর্ণনা |
---|---|
company.id | |
company.displayName | |
company.apps | |
company.appOwnerStatus | |
company.created_by | |
company.created_at | |
company.last_modified_at | |
company.last_modified_by | |
company.{custom_attributes} | সংস্থার একটি নামী কাস্টম বৈশিষ্ট্য। |
জেনারেটঅ্যান্ডোরাইজেশনকোড অপারেশন
জেনারেট আন্টিওহোরাইজেশনকোড অপারেশন সফলভাবে সম্পাদন করার সময় এই ভেরিয়েবলগুলি সেট করা হয়:
উপসর্গ: oauthv2authcode.{policy_name}.{variable_name}
উদাহরণ: oauthv2authcode.GenerateCodePolicy.code
পরিবর্তনশীল | বর্ণনা |
---|---|
code | নীতি কার্যকর করার সময় অনুমোদনের কোড উত্পন্ন হয়। |
redirect_uri | নিবন্ধিত ক্লায়েন্ট অ্যাপের সাথে যুক্ত পুনঃনির্দেশ ইউআরআই। |
scope | ক্লায়েন্টের অনুরোধে al চ্ছিক OAuth সুযোগ পাস হয়েছে। |
client_id | ক্লায়েন্ট আইডি ক্লায়েন্টের অনুরোধে পাস করেছে। |
জেনারেটএসেসটোকেন এবং রিফ্রেশঅ্যাকসেস টোকেন অপারেশন
জেনারেটএকসেসটোকেন এবং রিফ্রেশঅ্যাকসেসটোকেন অপারেশনগুলি সফলভাবে সম্পাদন করার সময় এই ভেরিয়েবলগুলি সেট করা হয়। নোট করুন যে রিফ্রেশ টোকেন ভেরিয়েবলগুলি ক্লায়েন্টের শংসাপত্রগুলি অনুদান ধরণের প্রবাহের জন্য প্রযোজ্য নয়।
উপসর্গ: oauthv2accesstoken.{policy_name}.{variable_name}
উদাহরণ: oauthv2accesstoken.GenerateTokenPolicy.access_token
পরিবর্তনশীল নাম | বর্ণনা |
---|---|
access_token | অ্যাক্সেস টোকেন যা উত্পন্ন হয়েছিল। |
client_id | এই টোকেনের সাথে যুক্ত বিকাশকারী অ্যাপের ক্লায়েন্ট আইডি। |
expires_in | টোকেনের জন্য মেয়াদোত্তীর্ণ মান। বিশদের জন্য <এক্সপায়ারসিন> উপাদানটি দেখুন। নোট করুন যে প্রতিক্রিয়াতে, মেয়াদোত্তীর্ণ_ইন কয়েক সেকেন্ডে প্রকাশ করা হয়। |
scope | টোকেনের জন্য কনফিগার করা স্কোপগুলির তালিকা। OAuth2 স্কোপগুলির সাথে কাজ করা দেখুন। |
status | হয় approved বা revoked । |
token_type | BearerToken সেট করা হয়। |
developer.email | টোকেনের সাথে সম্পর্কিত বিকাশকারী অ্যাপের মালিক নিবন্ধিত বিকাশকারীর ইমেল ঠিকানা। |
organization_name | Org যেখানে প্রক্সি কার্যকর করে। |
api_product_list | টোকেনের সংশ্লিষ্ট বিকাশকারী অ্যাপের সাথে যুক্ত পণ্যগুলির একটি তালিকা। |
refresh_count | |
refresh_token | রিফ্রেশ টোকেন যা উত্পন্ন হয়েছিল। নোট করুন যে ক্লায়েন্টের শংসাপত্র অনুদানের ধরণের জন্য রিফ্রেশ টোকেনগুলি উত্পন্ন হয় না। |
refresh_token_expires_in | রিফ্রেশ টোকেনের জীবনকাল, সেকেন্ডে। |
refresh_token_issued_at | এই সময়ের মান হ'ল সংশ্লিষ্ট 32-বিট টাইমস্ট্যাম্প পরিমাণের স্ট্রিং উপস্থাপনা। উদাহরণস্বরূপ, 'বুধ, 21 আগস্ট 2013 19:16:47 ইউটিসি' 1377112607413 এর টাইমস্ট্যাম্প মানের সাথে মিলে যায়। |
refresh_token_status | হয় approved বা revoked । |
জেনারেটএসেসেসটোকেনআইএমপিএলসিটিগ্র্যান্ট
এই ভেরিয়েবলগুলি সেট করা হয় যখন জেনারেটএসেসেসটোকনিমপ্লিকিটি অপারেশন অন্তর্নিহিত অনুদান প্রকার প্রবাহের জন্য সফলভাবে সম্পাদন করে।
উপসর্গ: oauthv2accesstoken.{policy_name}.{variable_name}
উদাহরণ: oauthv2accesstoken.RefreshTokenPolicy.access_token
পরিবর্তনশীল | বর্ণনা |
---|---|
oauthv2accesstoken.access_token | নীতি কার্যকর করার সময় অ্যাক্সেস টোকেন উত্পন্ন হয়। |
oauthv2accesstoken.{policy_name}.expires_in | টোকেনের জন্য মেয়াদোত্তীর্ণ মান, সেকেন্ডে। বিশদের জন্য <এক্সপায়ারসিন> উপাদানটি দেখুন। |
ত্রুটি উল্লেখ
This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.
Runtime errors
These errors can occur when the policy executes.
Fault code | HTTP status | Cause | Thrown by operations |
---|---|---|---|
steps.oauth.v2.access_token_expired |
401 | The access token is expired. |
VerifyAccessToken |
steps.oauth.v2.access_token_not_approved |
401 | The access token was revoked. | VerifyAccessToken |
steps.oauth.v2.apiresource_doesnot_exist |
401 | The requested resource does not exist any of the API products associated with the access token. | VerifyAccessToken |
steps.oauth.v2.FailedToResolveAccessToken |
500 | The policy expected to find an access token in a variable specified in the
<AccessToken> element, but the variable could not be resolved. |
GenerateAccessToken |
steps.oauth.v2.FailedToResolveAuthorizationCode |
500 | The policy expected to find an authorization code in a variable specified in the
<Code> element, but the variable could not be resolved. |
GenerateAuthorizationCode |
steps.oauth.v2.FailedToResolveClientId |
500 | The policy expected to find the Client ID in a variable specified in the
<ClientId> element, but the variable could not be resolved. |
GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken |
steps.oauth.v2.FailedToResolveRefreshToken |
500 | The policy expected to find a refresh token in a variable specified in the
<RefreshToken> element, but the variable could not be resolved. |
RefreshAccessToken |
steps.oauth.v2.FailedToResolveToken |
500 | The policy expected to find a token in a variable specified in the
<Tokens> element, but the variable could not be resolved. |
ValidateToken |
steps.oauth.v2.InsufficientScope |
403 | The access token presented in the request has a scope that does not match the scope specified in the verify access token policy. To learn about scope, see Working with OAuth2 scopes. | VerifyAccessToken |
steps.oauth.v2.invalid_access_token |
401 | The access token sent from the client is invalid. | VerifyAccessToken |
steps.oauth.v2.invalid_client |
401 |
This error name is returned when the Note: It is recommended that you change existing fault rule
conditions to catch both the |
GenerateAccessToken RefreshAccessToken |
steps.oauth.v2.InvalidRequest |
400 | This error name is used for multiple different kinds of errors, typically for missing
or incorrect parameters sent in the request. If <GenerateResponse> is
set to false , use fault variables (described below) to retrieve details about
the error, such as the fault name and cause. |
GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken |
steps.oauth.v2.InvalidAccessToken |
401 | The authorization header does not have the word "Bearer", which is required. For
example: Authorization: Bearer your_access_token |
VerifyAccessToken |
steps.oauth.v2.InvalidAPICallAsNoApiProductMatchFound |
401 |
The API proxy is not in the Product associated with the access token. Tips: Be sure that the product associated with the access token is configured correctly. For example, if you use wildcards in resource paths, be sure the wildcards are being used correctly. See Create API products for details. See also this Apigee Community post for more guidance on causes for this error. |
VerifyAccessToken |
steps.oauth.v2.InvalidClientIdentifier |
500 |
This error name is returned when the |
GenerateAccessToken |
steps.oauth.v2.InvalidParameter |
500 | The policy must specify either an access token or an authorization code, but not both. | GenerateAuthorizationCode GenerateAccessTokenImplicitGrant |
steps.oauth.v2.InvalidTokenType |
500 | The <Tokens>/<Token> element requires you to specify the token
type (for example, refreshtoken ). If the client passes the wrong type, this
error is thrown. |
ValidateToken InvalidateToken |
steps.oauth.v2.MissingParameter |
500 | The response type is token , but no grant types are specified. |
GenerateAuthorizationCode GenerateAccessTokenImplicitGrant |
steps.oauth.v2.UnSupportedGrantType |
500 |
The client specified a grant type that is unsupported by the policy (not listed in the <SupportedGrantTypes> element). Note: There is currently a bug where unsupported grant type errors are not thrown correctly. If an unsupported grant type error occurs, the proxy does not enter the Error Flow, as expected. |
GenerateAccessToken GenerateAuthorizationCode GenerateAccessTokenImplicitGrant RefreshAccessToken |
Deployment errors
These errors can occur when you deploy a proxy containing this policy.
Error name | Cause |
---|---|
InvalidValueForExpiresIn |
For the |
InvalidValueForRefreshTokenExpiresIn |
For the <RefreshTokenExpiresIn> element, valid values are positive
integers and -1 . |
InvalidGrantType |
An invalid grant type is specified in the <SupportedGrantTypes>
element. See the policy reference for a list of valid types. |
ExpiresInNotApplicableForOperation |
Be sure that the operations specified in the <Operations> element support expiration. For example, the VerifyToken operation does not. |
RefreshTokenExpiresInNotApplicableForOperation |
Be sure that the operations specified in the <Operations> element support refresh token expiration. For example, the VerifyToken operation does not. |
GrantTypesNotApplicableForOperation |
Be sure that the grant types specified in <SupportedGrantTypes> are supported for the specified operation. |
OperationRequired |
You must specify an operation in this policy using the Note: If the |
InvalidOperation |
You must specify a valid operation in this policy using the
Note: If the |
TokenValueRequired |
You must specify a token <Token> value in the
<Tokens> element. |
Fault variables
These variables are set when this policy triggers an error at runtime.
<GenerateResponse>
is set to
false
. If <GenerateResponse>
is
true
, the policy returns a response to the client immediately if an error occurs --
the error flow is skipped and these variables are not populated. For more information, see
What you need to
know about policy errors.Variables | Where | Example |
---|---|---|
fault.name="fault_name" |
fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. | fault.name = "InvalidRequest" |
oauthV2.policy_name.failed |
policy_name is the user-specified name of the policy that threw the fault. | oauthV2.GenerateAccesstoken.failed = true |
oauthV2.policy_name.fault.name |
policy_name is the user-specified name of the policy that threw the fault. | oauthV2.GenerateAccesstoken.fault.name = InvalidRequest
Note: For the VerifyAccessToken operation, the fault name includes this suffix: |
oauthV2.policy_name.fault.cause |
policy_name is the user-specified name of the policy that threw the fault. | oauthV2.GenerateAccesstoken.cause = Required param : grant_type |
Example error response
These responses are sent back to the client if the <GenerateResponse>
element is true.
errorcode
part of the error response. Do not rely on the text in the
faultstring
, because it could change.If <GenerateResponse>
is true, the policy returns errors
in this format for operations that generate tokens and codes. For a complete list, see see
OAuth HTTP error
response reference.
{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}
If <GenerateResponse>
is true, the policy returns errors
in this format for verify and validate operations. For a complete list, see see OAuth HTTP error
response reference.
{ { "fault":{ "faultstring":"Invalid Access Token", "detail":{ "errorcode":"keymanagement.service.invalid_access_token" } } }
Example fault rule
<FaultRule name=OAuthV2 Faults"> <Step> <Name>AM-InvalidClientResponse</Name> <Condition>(fault.name = "invalid_client") OR (fault.name = "InvalidClientIdentifier")</Condition> </Step> <Step> <Name>AM-InvalidTokenResponse</Name> <Condition>(fault.name = "invalid_access_token")</Condition> </Step> <Condition>(oauthV2.failed = true) </Condition> </FaultRule>
নীতি স্কিমা
প্রতিটি নীতির ধরন একটি XML স্কিমা ( .xsd
) দ্বারা সংজ্ঞায়িত করা হয়। রেফারেন্সের জন্য, নীতি স্কিমা GitHub এ উপলব্ধ।
ডিফল্ট OAuth কনফিগারেশন নিয়ে কাজ করা
অ্যাপিগি প্রান্তে প্রতিটি সংস্থা (এমনকি একটি নিখরচায় ট্রায়াল অর্গ) একটি OAuth টোকেন এন্ডপয়েন্টের সাথে বিধান করা হয়। শেষ পয়েন্টটি এপিআই প্রক্সিতে ওআউথ নামক নীতিগুলির সাথে পূর্বনির্ধারিত। আপনি অ্যাপিগি প্রান্তে একটি অ্যাকাউন্ট তৈরি করার সাথে সাথে আপনি টোকেন এন্ডপয়েন্টটি ব্যবহার শুরু করতে পারেন। বিশদগুলির জন্য, ওআউথ এন্ডপয়েন্টগুলি বোঝার দেখুন।
অ্যাক্সেস টোকেন শুদ্ধ করা
ডিফল্টরূপে, OAuth2 টোকেনগুলি এপিগি এজ সিস্টেম থেকে 3 দিন (259200 সেকেন্ড) থেকে শুদ্ধ হয় তবে অ্যাক্সেস টোকেন এবং রিফ্রেশ টোকেন (যদি এটি উপস্থিত থাকে) উভয়ই মেয়াদোত্তীর্ণ হওয়ার পরে। কিছু ক্ষেত্রে, আপনি এই ডিফল্টটি পরিবর্তন করতে চাইতে পারেন। উদাহরণস্বরূপ, আপনি যদি বিপুল সংখ্যক টোকেন উত্পন্ন হয় তবে আপনি ডিস্কের স্থান সংরক্ষণের জন্য শুদ্ধ সময়টি সংক্ষিপ্ত করতে চাইতে পারেন।
আপনি যদি ব্যক্তিগত মেঘের জন্য প্রান্তে থাকেন তবে আপনি এই বিভাগে বর্ণিত হিসাবে সংস্থার বৈশিষ্ট্যগুলি সেট করে এই ডিফল্টটি পরিবর্তন করতে পারেন। (মেয়াদোত্তীর্ণ টোকেনের 3 দিনের শুদ্ধতা প্রাইভেট ক্লাউড সংস্করণ 4.19.01 এবং তার পরে প্রান্তে প্রযোজ্য। পূর্ববর্তী সংস্করণগুলির জন্য, ডিফল্ট শুদ্ধ ব্যবধান 180 দিন হয়))
এজ প্রাইভেট ক্লাউড 4.16.01 এবং পরবর্তী সংস্করণগুলির জন্য পিউর সেটিংস আপডেট করা হচ্ছে
দ্রষ্টব্য: এই সেটিংস প্রয়োগের পরে উত্পন্ন টোকেনগুলি প্রভাবিত হয়; সেটিংস আগে উত্পন্ন টোকেনগুলিতে প্রযোজ্য নয়।
- সম্পাদনার জন্য এই ফাইলটি খুলুন:
/opt/apigee/customer/application/message-processor.properties
- টোকেনটির মেয়াদ শেষ হওয়ার পরে শুদ্ধ করার আগে অপেক্ষা করতে সেকেন্ডের সংখ্যা নির্ধারণের জন্য নিম্নলিখিত সম্পত্তিটি যুক্ত করুন:
conf_keymanagement_oauth.access.token.purge.after.seconds=<number of seconds>
- বার্তা প্রসেসর পুনরায় চালু করুন। যেমন:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
<ExpiresIn>
এবং <RefreshTokenExpiresIn>
বৈশিষ্ট্যগুলি ব্যবহার করে OAUTHV2 নীতিতে টোকেন মেয়াদোত্তীর্ণতা সেট করতে পারেন। এজ প্রাইভেট ক্লাউড 4.15.07 এর জন্য শুদ্ধ সেটিংস আপডেট করা হচ্ছে
দ্রষ্টব্য: এই সেটিংস প্রয়োগের পরে উত্পন্ন টোকেনগুলি প্রভাবিত হয়; সেটিংস আগে উত্পন্ন টোকেনগুলিতে প্রযোজ্য নয়।
OAUTHV2 নীতিমালায়
<ExpiresIn>
এবং<RefreshTokenExpiresIn>
বৈশিষ্ট্যগুলির জন্য ইতিবাচক মানগুলি সেট করুন। মানগুলি মিলিসেকেন্ডে। যেমন:<ExpiresIn>1000</ExpiresIn> <RefreshTokenExpiresIn>10000</RefreshTokenExpiresIn>
প্রক্সি পুনরায় নিয়োগ করুন।
আপনার সংস্থার জন্য টোকেন পিউরি বৈশিষ্ট্যগুলি আপডেট করতে এই এপিআই ব্যবহার করুন:
POST https://<host-name>/v1/organizations/<org-name>
পেলোড:
<Organization name="AutomationOrganization"> <Description>Desc</Description> <Properties> <Property name="keymanagement.oauth20.access.token.purge">true</Property> <Property name="keymanagement.oauth20.access.token.purge.after.seconds">120</Property> </Properties> </Organization>
বার্তা প্রসেসর পুনরায় চালু করুন। যেমন:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
এই এপিআই অটোমেশনঅরগানাইজেশন নামক সংস্থার জন্য টোকেন শুদ্ধ সম্পত্তিটিকে সত্যে সেট করে। এই ক্ষেত্রে, অ্যাক্সেস টোকেনটি টোকেন এবং রিফ্রেশ টোকেন উভয়ের মেয়াদ শেষ হওয়ার পরে 120 সেকেন্ডের ডাটাবেস থেকে শুদ্ধ হবে।
নন-আরএফসি-অনুগত আচরণ
OAUTHV2 নীতিটি একটি টোকেন প্রতিক্রিয়া প্রদান করে যাতে নির্দিষ্ট অ- আরএফসি-অনুগত বৈশিষ্ট্য রয়েছে। নিম্নলিখিত টেবিলটি OAUTHV2 নীতি এবং সংশ্লিষ্ট মেনে চলার বৈশিষ্ট্য দ্বারা ফিরে আসা অ-কমপ্লায়েন্ট বৈশিষ্ট্যগুলি দেখায়।
Oauthv2 রিটার্ন: | আরএফসি-অনুগত সম্পত্তি হ'ল: |
---|---|
"token_type":"BearerToken" | "token_type":"Bearer" |
"expires_in":"3600" | "expires_in":3600 (অনুগত মানটি একটি সংখ্যা, স্ট্রিং নয়)) |
এছাড়াও, যখন grant_type = refresh_token
হয় তখন মেয়াদোত্তীর্ণ রিফ্রেশ টোকেনের জন্য ত্রুটি প্রতিক্রিয়া:
{"ErrorCode" : "InvalidRequest", "Error" :"Refresh Token expired"}
তবে, আরএফসি-অনুগত প্রতিক্রিয়া হ'ল:
{"error" : "invalid_grant", "error_description" :"refresh token expired"}