OAuthV2 নীতি

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

কি

OAuthV2 হল OAuth 2.0 অনুদান টাইপ অপারেশন সম্পাদনের জন্য একটি বহুমুখী নীতি৷ এটি Apigee Edge-এ OAuth 2.0 এন্ডপয়েন্ট কনফিগার করতে ব্যবহৃত প্রাথমিক নীতি।

টিপ: আপনি যদি Apigee Edge-এ OAuth সম্পর্কে আরও জানতে চান, OAuth হোম পেজ দেখুন। এটি সম্পদ, নমুনা, ভিডিও এবং আরও অনেক কিছুর লিঙ্ক প্রদান করে। একটি কার্যকরী অ্যাপ্লিকেশনে এই নীতিটি কীভাবে ব্যবহার করা হয় তার একটি ভাল প্রদর্শনের জন্য GitHub-এ উন্নত OAuth নমুনা দেখুন।

নমুনা

<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>

$ curl -H "Authorization: Bearer ylSkZIjbdWybfsUQe9BqP0LH5Z" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282

<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>

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">

নিম্নলিখিত সারণী সমস্ত নীতির মূল উপাদানগুলির জন্য সাধারণ বৈশিষ্ট্যগুলি বর্ণনা করে:

<DisplayName> উপাদান

ম্যানেজমেন্ট UI প্রক্সি এডিটরে নীতিটিকে একটি ভিন্ন, প্রাকৃতিক-ভাষা নামের সাথে লেবেল করতে name বৈশিষ্ট্য ছাড়াও ব্যবহার করুন।

<DisplayName>Policy Display Name</DisplayName>

<AccessToken> উপাদান

<AccessToken>request.header.access_token</AccessToken>

ডিফল্টরূপে, VerifyAccessToken আশা করে যে Authorization শিরোনামে অ্যাক্সেস টোকেন পাঠানো হবে। আপনি এই উপাদান ব্যবহার করে যে ডিফল্ট পরিবর্তন করতে পারেন. উদাহরণস্বরূপ, request.queryparam.access_token নির্দেশ করে যে অ্যাক্সেস টোকেনটি access_token নামের একটি ক্যোয়ারী প্যারামিটার হিসাবে উপস্থিত থাকা উচিত।

curl https://myorg-myenv.apigee.net/oauth2/validate -H "access_token:Rft3dqrs56Blirls56a"

curl "https://myorg-myenv.apigee.net/oauth2/validate?access_token:Rft3dqrs56Blirls56a"

<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 অ্যাক্সেস টোকেনগুলির পুনরুদ্ধার এবং প্রত্যাহার সক্ষম করুন দেখুন৷

<অ্যাট্রিবিউটস/অ্যাট্রিবিউট>

<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 সেট করা সমর্থিত নয়। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.

<কোড> উপাদান

<Code>request.queryparam.code</Code>

অনুমোদনের অনুদানের প্রকারের প্রবাহে, ক্লায়েন্টকে অবশ্যই অনুমোদন সার্ভারে (Apigee Edge) একটি অনুমোদন কোড জমা দিতে হবে। এই উপাদানটি আপনাকে নির্দিষ্ট করতে দেয় যে প্রান্তের অনুমোদন কোডটি কোথায় দেখা উচিত। উদাহরণস্বরূপ, এটি একটি ক্যোয়ারী প্যারামিটার, HTTP হেডার, বা ফর্ম প্যারামিটার (ডিফল্ট) হিসাবে পাঠানো যেতে পারে।

ভেরিয়েবল, request.queryparam.auth_code ইঙ্গিত করে যে অনুমোদন কোডটি একটি কোয়েরি প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, যেমন, উদাহরণস্বরূপ, ?auth_code=AfGlvs9 । একটি HTTP শিরোনামে অনুমোদন কোড প্রয়োজন, উদাহরণস্বরূপ, এই মানটি request.header.auth_code এ সেট করুন। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.

<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 বৈশিষ্ট্য দ্বারা সেট করা হয়। এই সম্পত্তি সেট করতে:

1. একটি এডিটরে message-processor.properties ফাইলটি খুলুন। ফাইলটি বিদ্যমান না থাকলে, এটি তৈরি করুন:

   vi /opt/apigee/customer/application/message-processor.properties

2. পছন্দ অনুযায়ী সম্পত্তি সেট করুন:

   conf_keymanagement_oauth_auth_code_expiry_time_in_millis=3600000

3. নিশ্চিত করুন যে বৈশিষ্ট্য ফাইলটি "apigee" ব্যবহারকারীর মালিকানাধীন:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. মেসেজ প্রসেসর রিস্টার্ট করুন।

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

<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 এ সেট করুন। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.

<অপারেশন> উপাদান

<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 বিকাশকারীর উপর নির্ভর করে।

এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.

<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 তে সেট করুন। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.

<রিফ্রেশটোকেন> উপাদান

<RefreshToken>request.queryparam.refreshtoken</RefreshToken>

রিফ্রেশ টোকেন ব্যবহার করে একটি অ্যাক্সেস টোকেন অনুরোধ করার সময়, আপনাকে অনুরোধে রিফ্রেশ টোকেন সরবরাহ করতে হবে। এই উপাদানটি আপনাকে নির্দিষ্ট করতে দেয় যে প্রান্তটি রিফ্রেশ টোকেনের জন্য কোথায় সন্ধান করবে৷ উদাহরণস্বরূপ, এটি একটি ক্যোয়ারী প্যারামিটার, HTTP হেডার, বা ফর্ম প্যারামিটার (ডিফল্ট) হিসাবে পাঠানো যেতে পারে।

ভেরিয়েবল request.queryparam.refreshtoken ইঙ্গিত করে যে রিফ্রেশ টোকেন একটি ক্যোয়ারী প্যারামিটার হিসাবে উপস্থিত থাকা উচিত, উদাহরণস্বরূপ, ?refresh_token=login.myapp.com । একটি HTTP হেডারে RefreshToken প্রয়োজনের জন্য, উদাহরণস্বরূপ, এই মানটি request.header.refresh_token এ সেট করুন। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.

<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 বৈশিষ্ট্য দ্বারা সেট করা হয়। এই সম্পত্তি সেট করতে:

1. একটি এডিটরে message-processor.properties ফাইলটি খুলুন। ফাইলটি বিদ্যমান না থাকলে, এটি তৈরি করুন:

   vi /opt/apigee/customer/application/message-processor.properties

2. পছন্দ অনুযায়ী সম্পত্তি সেট করুন:

   conf_keymanagement_oauth_refresh_token_expiry_time_in_millis=3600000

3. নিশ্চিত করুন যে বৈশিষ্ট্য ফাইলটি "apigee" ব্যবহারকারীর মালিকানাধীন:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. মেসেজ প্রসেসর রিস্টার্ট করুন।

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

<ResponseType> উপাদান

<ResponseType>request.queryparam.response_type</ResponseType>

এই উপাদানটি এজকে জানায় যে ক্লায়েন্ট অ্যাপটি কোন ধরনের অনুদান অনুরোধ করছে। এটি শুধুমাত্র অনুমোদন কোড এবং অন্তর্নিহিত অনুদান প্রকার প্রবাহের সাথে ব্যবহার করা হয়।

ডিফল্টরূপে, এজ response_type ক্যোয়ারী প্যারামিটারে রেসপন্স টাইপ মান খোঁজে। আপনি যদি এই ডিফল্ট আচরণকে ওভাররাইড করতে চান, তাহলে প্রতিক্রিয়া প্রকার মান সহ একটি ফ্লো ভেরিয়েবল কনফিগার করতে <ResponseType> উপাদানটি ব্যবহার করুন। উদাহরণস্বরূপ, আপনি যদি এই উপাদানটি request.header.response_type এ সেট করেন, তাহলে এজ অনুরোধের শিরোনামে পাস করা প্রতিক্রিয়ার ধরনটি সন্ধান করে। এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.

<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 স্কোপের সাথে কাজ করা এবং অ্যাক্সেস টোকেন এবং অনুমোদন কোডের অনুরোধ করা দেখুন।

<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 বিকাশকারীর উপর নির্ভর করে।

এছাড়াও অ্যাক্সেস টোকেন এবং অনুমোদন কোড অনুরোধ দেখুন.

অ্যাক্সেস টোকেন যাচাই করা

একবার একটি এপিআই প্রক্সি জন্য একটি টোকেন এন্ডপয়েন্ট সেট আপ করা হলে, একটি সংশ্লিষ্ট 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>

অ্যাক্সেস টোকেনগুলি যাচাই করা এবং অ্যাক্সেস টোকেন এবং অনুমোদনের কোডগুলির জন্য অনুরোধ করাও দেখুন।

অনুরোধ পরিবর্তনশীল অবস্থান নির্দিষ্ট করে

প্রতিটি অনুদানের ধরণের জন্য, নীতিটি অনুরোধ বার্তাগুলিতে অবস্থান বা প্রয়োজনীয় তথ্য সম্পর্কে অনুমান করে। এই অনুমানগুলি 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 নীতিগুলি কার্যকর করা হয় এবং তাই এপিআই প্রক্সি প্রবাহে কার্যকর করা অন্যান্য নীতি বা অ্যাপ্লিকেশনগুলির জন্য উপলব্ধ।

যাচাই -অ্যাক্সেস টোকেন অপারেশন

যাচাই -অ্যাক্সেস টোকেন অপারেশন কার্যকর করে, প্রক্সির কার্যকরকরণের প্রসঙ্গে প্রচুর পরিমাণে প্রবাহের ভেরিয়েবলগুলি পপুলেট করা হয়। এই ভেরিয়েবলগুলি আপনাকে অ্যাক্সেস টোকেন, বিকাশকারী অ্যাপ্লিকেশন, বিকাশকারী এবং সংস্থা সম্পর্কিত বৈশিষ্ট্য দেয়। আপনি একটি অ্যাসাইনমেসেজ বা জাভাস্ক্রিপ্ট নীতি ব্যবহার করতে পারেন, উদাহরণস্বরূপ, এই ভেরিয়েবলগুলির যে কোনওটি পড়তে এবং প্রবাহের পরে প্রয়োজনীয় হিসাবে সেগুলি ব্যবহার করতে পারেন। এই ভেরিয়েবলগুলি ডিবাগিংয়ের উদ্দেশ্যেও কার্যকর হতে পারে।

টোকেন-নির্দিষ্ট ভেরিয়েবল

অ্যাপ্লিকেশন-নির্দিষ্ট ভেরিয়েবল

এই ভেরিয়েবলগুলি টোকেনের সাথে সম্পর্কিত বিকাশকারী অ্যাপের সাথে সম্পর্কিত।

বিকাশকারী-নির্দিষ্ট ভেরিয়েবল

যদি অ্যাপ.এপ টাইপটি "সংস্থা" হয়, তবে সংস্থার বৈশিষ্ট্যগুলি পপুলেটেড হয় এবং যদি অ্যাপ্লিকেশন.এপ টাইপ "বিকাশকারী" হয় তবে বিকাশকারী বৈশিষ্ট্যগুলি পপুলেটেড হয়।

সংস্থা-নির্দিষ্ট ভেরিয়েবল

যদি অ্যাপ.এপ টাইপটি "সংস্থা" হয়, তবে সংস্থার বৈশিষ্ট্যগুলি পপুলেটেড হয় এবং যদি অ্যাপ্লিকেশন.এপ টাইপ "বিকাশকারী" হয় তবে বিকাশকারী বৈশিষ্ট্যগুলি পপুলেটেড হয়।

জেনারেটঅ্যান্ডোরাইজেশনকোড অপারেশন

জেনারেট আন্টিওহোরাইজেশনকোড অপারেশন সফলভাবে সম্পাদন করার সময় এই ভেরিয়েবলগুলি সেট করা হয়:

উপসর্গ: oauthv2authcode.{policy_name}.{variable_name}

উদাহরণ: oauthv2authcode.GenerateCodePolicy.code

জেনারেটএসেসটোকেন এবং রিফ্রেশঅ্যাকসেস টোকেন অপারেশন

জেনারেটএকসেসটোকেন এবং রিফ্রেশঅ্যাকসেসটোকেন অপারেশনগুলি সফলভাবে সম্পাদন করার সময় এই ভেরিয়েবলগুলি সেট করা হয়। নোট করুন যে রিফ্রেশ টোকেন ভেরিয়েবলগুলি ক্লায়েন্টের শংসাপত্রগুলি অনুদান ধরণের প্রবাহের জন্য প্রযোজ্য নয়।

উপসর্গ: oauthv2accesstoken.{policy_name}.{variable_name}

উদাহরণ: oauthv2accesstoken.GenerateTokenPolicy.access_token

জেনারেটএসেসেসটোকেনআইএমপিএলসিটিগ্র্যান্ট

এই ভেরিয়েবলগুলি সেট করা হয় যখন জেনারেটএসেসেসটোকনিমপ্লিকিটি অপারেশন অন্তর্নিহিত অনুদান প্রকার প্রবাহের জন্য সফলভাবে সম্পাদন করে।

উপসর্গ: oauthv2accesstoken.{policy_name}.{variable_name}

উদাহরণ: oauthv2accesstoken.RefreshTokenPolicy.access_token

ত্রুটি উল্লেখ

এই বিভাগটি ফল্ট কোড এবং ত্রুটি বার্তাগুলি বর্ণনা করে যেগুলি ফেরত দেওয়া হয় এবং ত্রুটি ভেরিয়েবলগুলি যেগুলি এজ দ্বারা সেট করা হয় যখন এই নীতিটি একটি ত্রুটি ট্রিগার করে৷ এই তথ্যটি জানা গুরুত্বপূর্ণ যে আপনি ত্রুটিগুলি পরিচালনা করার জন্য ত্রুটির নিয়ম তৈরি করছেন কিনা। আরও জানতে, নীতিগত ত্রুটি এবং হ্যান্ডলিং ফল্ট সম্পর্কে আপনার যা জানা দরকার তা দেখুন৷

রানটাইম ত্রুটি

নীতি কার্যকর করার সময় এই ত্রুটিগুলি ঘটতে পারে৷

স্থাপনার ত্রুটি

আপনি যখন এই নীতি সম্বলিত একটি প্রক্সি স্থাপন করেন তখন এই ত্রুটিগুলি ঘটতে পারে৷

ফল্ট ভেরিয়েবল

যখন এই নীতি রানটাইমে একটি ত্রুটি ট্রিগার করে তখন এই ভেরিয়েবলগুলি সেট করা হয়৷

উদাহরণ ত্রুটি প্রতিক্রিয়া

<GenerateResponse> উপাদানটি সত্য হলে এই প্রতিক্রিয়াগুলি ক্লায়েন্টের কাছে ফেরত পাঠানো হয়।

যদি <GenerateResponse> সত্য হয়, টোকেন এবং কোড তৈরি করে এমন ক্রিয়াকলাপগুলির জন্য নীতিটি এই বিন্যাসে ত্রুটিগুলি প্রদান করে৷ একটি সম্পূর্ণ তালিকার জন্য, OAuth HTTP ত্রুটি প্রতিক্রিয়া রেফারেন্স দেখুন।

{"ErrorCode" : "invalid_client", "Error" :"ClientId is Invalid"}

যদি <GenerateResponse> সত্য হয়, নীতিটি এই বিন্যাসে ত্রুটিগুলি প্রদান করে অপারেশনগুলি যাচাই ও যাচাই করার জন্য৷ একটি সম্পূর্ণ তালিকার জন্য, OAuth HTTP ত্রুটি প্রতিক্রিয়া রেফারেন্স দেখুন।

{  
   {  
      "fault":{  
         "faultstring":"Invalid Access Token",
         "detail":{  
            "errorcode":"keymanagement.service.invalid_access_token"
         }
      }
   }

উদাহরণ দোষ নিয়ম

<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 এবং পরবর্তী সংস্করণগুলির জন্য পিউর সেটিংস আপডেট করা হচ্ছে

দ্রষ্টব্য: এই সেটিংস প্রয়োগের পরে উত্পন্ন টোকেনগুলি প্রভাবিত হয়; সেটিংস আগে উত্পন্ন টোকেনগুলিতে প্রযোজ্য নয়।

এজ প্রাইভেট ক্লাউড 4.15.07 এর জন্য শুদ্ধ সেটিংস আপডেট করা হচ্ছে

দ্রষ্টব্য: এই সেটিংস প্রয়োগের পরে উত্পন্ন টোকেনগুলি প্রভাবিত হয়; সেটিংস আগে উত্পন্ন টোকেনগুলিতে প্রযোজ্য নয়।

নন-আরএফসি-অনুগত আচরণ

OAUTHV2 নীতিটি একটি টোকেন প্রতিক্রিয়া প্রদান করে যাতে নির্দিষ্ট অ- আরএফসি-অনুগত বৈশিষ্ট্য রয়েছে। নিম্নলিখিত টেবিলটি OAUTHV2 নীতি এবং সংশ্লিষ্ট মেনে চলার বৈশিষ্ট্য দ্বারা ফিরে আসা অ-কমপ্লায়েন্ট বৈশিষ্ট্যগুলি দেখায়।

এছাড়াও, যখন grant_type = refresh_token হয় তখন মেয়াদোত্তীর্ণ রিফ্রেশ টোকেনের জন্য ত্রুটি প্রতিক্রিয়া:

{"ErrorCode" : "invalid_request", "Error" :"Refresh Token expired"}

তবে, আরএফসি-অনুগত প্রতিক্রিয়া হ'ল:

{"error" : "invalid_grant", "error_description" :"refresh token expired"}

সম্পর্কিত বিষয়

• OAuth 2.0 এর ভূমিকা