প্রাইভেট স্টেট টোকেন ডেভেলপার গাইড

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

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

প্রাইভেট স্টেট টোকেন (পূর্বে ট্রাস্ট টোকেন নামে পরিচিত) ব্যবহারকারীর সত্যতার উপর আস্থা এক প্রেক্ষাপট থেকে অন্য প্রেক্ষাপটে পৌঁছে দেওয়ার সুযোগ দেয়, একই সাথে সাইটগুলিকে জালিয়াতির বিরুদ্ধে লড়াই করতে এবং বটকে প্রকৃত মানুষ থেকে আলাদা করতে সাহায্য করে—প্যাসিভ ট্র্যাকিং ছাড়াই।

এই নথিতে প্রাইভেট স্টেট টোকেন (PST) বাস্তবায়নের জন্য প্রযুক্তিগত বিবরণের রূপরেখা দেওয়া হয়েছে। আরও উচ্চ-স্তরের রূপরেখার জন্য, PST ওভারভিউ দেখুন।

প্রাইভেট স্টেট টোকেন কিভাবে কাজ করে?

PST-তে বোঝার জন্য মূল সম্পর্ক হল ইস্যুকারী এবং রিডিমারদের মধ্যে। ইস্যুকারী এবং রিডিমার একই কোম্পানির মধ্যে থাকতে পারে।

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

প্রতিটি PST ইন্টারঅ্যাকশনের জন্য ইস্যুকারী এবং রিডিমারদের একসাথে কাজ করে ওয়েব জুড়ে সিগন্যাল শেয়ার করতে হয়। এই সিগন্যালগুলি মোটামুটি মান যা ব্যক্তিদের সনাক্ত করার জন্য যথেষ্ট বিশদ নয়।

প্রাইভেট স্টেট টোকেন কি আমার জন্য সঠিক?

যেসব কোম্পানি বিশ্বাসযোগ্য সিদ্ধান্ত নিচ্ছে এবং তথ্য বিভিন্ন প্রেক্ষাপটে উপলব্ধ করতে চায় তারা PST থেকে উপকৃত হতে পারে। PST-এর সম্ভাব্য ব্যবহারের ক্ষেত্রে আরও জানতে, PST ব্যবহারের ক্ষেত্রে আমাদের ডকুমেন্টেশন দেখুন।

টোকেন ইস্যু এবং রিডিম করুন

পিএসটি বাস্তবায়ন তিনটি পর্যায়ে ঘটে:

1. টোকেন ইস্যু করা
2. টোকেন রিডিম করা হচ্ছে
3. রিডেম্পশন রেকর্ড ফরওয়ার্ডিং

প্রথম পর্যায়ে, টোকেনগুলি একটি ব্রাউজারে জারি করা হয় (সাধারণত কোনও ধরণের যাচাইয়ের পরে)। দ্বিতীয় পর্যায়ে, অন্য একটি সত্তা সেই টোকেনের মান পড়ার জন্য ইস্যু করা টোকেনটি খালাস করার জন্য অনুরোধ করবে। চূড়ান্ত পর্যায়ে, খালাসকারী পক্ষ টোকেনে থাকা মান সহ একটি খালাস রেকর্ড (RR) পাবে। সেই খালাসকারী পক্ষ তখন সেই রেকর্ডটি বিভিন্ন উদ্দেশ্যে সেই ব্যবহারকারীর সত্যায়ন হিসাবে ব্যবহার করতে পারে।

আপনার টোকেন কৌশল নির্ধারণ করুন

আপনার টোকেন কৌশল সংজ্ঞায়িত করার জন্য, আপনার ব্যবহারের ক্ষেত্রে তাদের সম্ভাব্য ব্যবহার সম্পর্কে চিন্তা করার জন্য আপনাকে PST মূল ধারণাগুলি (টোকেন এবং রিডেম্পশন রেকর্ড), ভেরিয়েবল, আচরণ এবং সীমাবদ্ধতাগুলি বুঝতে হবে।

টোকেন এবং রিডেম্পশন রেকর্ড: তাদের মধ্যে সম্পর্ক কী?

প্রতিটি ডিভাইস প্রতিটি শীর্ষ-স্তরের ওয়েবসাইট এবং ইস্যুকারীর জন্য 500টি পর্যন্ত টোকেন সংরক্ষণ করতে পারে। এছাড়াও, প্রতিটি টোকেনে মেটাডেটা থাকে যা ইস্যুকারী কোন কী ব্যবহার করে এটি ইস্যু করেছে তা জানায়। রিডিমিং প্রক্রিয়া চলাকালীন টোকেন রিডিম করা বা না করার সিদ্ধান্ত নিতে এই তথ্য ব্যবহার করা যেতে পারে। PST ডেটা ব্যবহারকারীর ডিভাইসে ব্রাউজার দ্বারা অভ্যন্তরীণভাবে সংরক্ষণ করা হয় এবং শুধুমাত্র PST API দ্বারা অ্যাক্সেস করা যেতে পারে।

যখন একটি টোকেন রিডিম করা হয়, তখন রিডিম্পশন রেকর্ড (RR) ডিভাইসে সংরক্ষণ করা হয়। এই স্টোরেজ ভবিষ্যতের রিডিমশনের জন্য একটি ক্যাশে হিসেবে কাজ করে। ডিভাইস, পৃষ্ঠা এবং ইস্যুকারীর জন্য প্রতি 48 ঘন্টা অন্তর দুটি টোকেন রিডিমশনের সীমা রয়েছে। নতুন রিডিমশন কলগুলি ইস্যুকারীর কাছে অনুরোধ করার পরিবর্তে, যেখানে সম্ভব ক্যাশে করা RR ব্যবহার করবে।

1. নতুন টোকেন জারি করা হয় (প্রতি ইস্যুকারী, সাইট এবং ডিভাইসের জন্য সর্বোচ্চ ৫০০)।
2. সমস্ত টোকেন ডিভাইসের টোকেন স্টোরে সংরক্ষণ করা হয় (কুকি স্টোরের মতো)।
3. যদি কোনও সক্রিয় RR পাওয়া না যায়, তাহলে ইস্যু করার পরে নতুন RR তৈরি করা যেতে পারে (প্রতি 48 ঘন্টায় সর্বোচ্চ 2টি)।
4. মেয়াদ শেষ না হওয়া পর্যন্ত RR গুলিকে সক্রিয় বলে মনে করা হয় এবং সেগুলি স্থানীয় ক্যাশে হিসেবে ব্যবহার করা হবে।
5. নতুন রিডেম্পশন কলগুলি স্থানীয় ক্যাশে আঘাত করবে (কোনও নতুন RR তৈরি হবে না)।

আপনার ব্যবহারের ক্ষেত্রে সংজ্ঞায়িত করার পরে, আপনাকে অবশ্যই আপনার RR-এর জীবনকাল সাবধানে নির্ধারণ করতে হবে কারণ এটি নির্ধারণ করবে যে আপনি আপনার ক্ষেত্রে কতবার সেগুলি ব্যবহার করতে পারবেন।

আপনার কৌশল নির্ধারণ করার আগে নিশ্চিত করুন যে আপনি নিম্নলিখিত সমালোচনামূলক আচরণ এবং পরিবর্তনশীলগুলি বুঝতে পেরেছেন:

উদাহরণ পরিস্থিতি

পরিস্থিতি #১: RR এর জীবনকাল ২৪ ঘন্টার কম (t=t) এবং ৪৮ ঘন্টার সময়কালে একাধিকবার রিডেম্পশন করা হয়।

পরিস্থিতি #২: RR এর জীবনকাল ২৪ ঘন্টা এবং ৪৮ ঘন্টার মধ্যে একাধিকবার রিডেম্পশন করা হয়।

পরিস্থিতি #৩: RR এর জীবনকাল ৪৮ ঘন্টা এবং ৪৮ ঘন্টার মধ্যে একাধিকবার রিডেম্পশন করা হয়।

ডেমো চালান

PST গ্রহণ করার আগে, আমরা ডেমো দিয়ে সেট আপ করার পরামর্শ দিচ্ছি।

এই ডেমোটি চালানোর মাধ্যমে, আপনার ব্রাউজার টোকেন সরবরাহ এবং ব্যবহার করার জন্য ডেমো ইস্যুকারী এবং রিডিমার সার্ভার ব্যবহার করছে।

প্রযুক্তিগত বিবেচনা

নিম্নলিখিত ধাপগুলি বাস্তবায়ন করলে ডেমোটি সবচেয়ে ভালোভাবে কাজ করবে:

• ফ্ল্যাগ সহ Chrome চালানোর আগে নিশ্চিত করুন যে আপনি সমস্ত Chrome ইনস্ট্যান্স বন্ধ করে দিয়েছেন।
• যদি আপনি উইন্ডোজ মেশিন ব্যবহার করেন, তাহলে Chrome এক্সিকিউটেবল বাইনারিতে প্যারামিটারগুলি কীভাবে পাস করবেন সে সম্পর্কে এই নির্দেশিকাটি একবার দেখে নিন।
• ডেমো অ্যাপ্লিকেশন ব্যবহার করার সময়, ডেমো ইস্যুকারী কর্তৃক ইস্যু করা বা রিডিম করা টোকেনগুলি দেখতে , অ্যাপ্লিকেশন > স্টোরেজ > প্রাইভেট স্টেট টোকেনগুলির অধীনে Chrome DevTools খুলুন।

দত্তক নেওয়ার জন্য প্রস্তুত

এই বিভাগটি PST ইস্যুকারী বা রিডিমার হওয়ার প্রয়োজনীয়তাগুলি ব্যাখ্যা করে।

ইস্যুকারী হন

PST-তে ইস্যুকারীরা গুরুত্বপূর্ণ ভূমিকা পালন করে। ব্যবহারকারী বট কিনা তা নির্ধারণের জন্য তারা টোকেনের মান নির্ধারণ করে। আপনি যদি ইস্যুকারী হিসেবে PST-এর সাথে শুরু করতে চান, তাহলে আপনাকে ইস্যুকারী নিবন্ধন প্রক্রিয়া সম্পন্ন করে নিবন্ধন করতে হবে।

ইস্যুকারী হওয়ার জন্য আবেদন করতে হলে, ইস্যুকারী ওয়েবসাইটের অপারেটরকে "নতুন PST ইস্যুকারী" টেমপ্লেট ব্যবহার করে GitHub রিপোজিটরিতে একটি নতুন ইস্যু খুলতে হবে। ইস্যুটি পূরণ করার জন্য রিপোজিটরির নির্দেশিকা অনুসরণ করুন। একবার একটি এন্ডপয়েন্ট যাচাই হয়ে গেলে, এটি এই রিপোজিটরিতে মার্জ করা হবে এবং Chrome সার্ভার-সাইড অবকাঠামো সেই কীগুলি আনতে শুরু করবে।

ইস্যুকারী সার্ভার

ইস্যুকারী এবং রিডিমাররা PST-এর মূল অভিনেতা; সার্ভার এবং টোকেন হল PST-এর মূল হাতিয়ার। যদিও আমরা ইতিমধ্যেই টোকেন সম্পর্কে কিছু বিবরণ এবং GitHub ডকুমেন্টেশনে প্রদান করেছি, আমরা PST সার্ভার সম্পর্কে আরও বিশদ অফার করতে চেয়েছিলাম। PST-এর ইস্যুকারী হিসেবে সেট আপ করার জন্য, আপনাকে প্রথমে একটি ইস্যুকারী সার্ভার সেট আপ করতে হবে।

আপনার পরিবেশ স্থাপন করুন: ইস্যুকারী সার্ভার

টোকেন ইস্যুকারী সার্ভার বাস্তবায়নের জন্য আপনাকে HTTP এন্ডপয়েন্টগুলি প্রকাশ করে আপনার নিজস্ব সার্ভার সাইড অ্যাপ্লিকেশন তৈরি করতে হবে।

ইস্যুয়ার কম্পোনেন্ট দুটি প্রধান মডিউল নিয়ে গঠিত: (১) ইস্যুয়ার সার্ভার এবং (২) টোকেন ইস্যুয়ার।

সমস্ত ওয়েব-ফেসিং অ্যাপ্লিকেশনের মতো, আমরা আপনার ইস্যুকারী সার্ভারে সুরক্ষার একটি অতিরিক্ত স্তর সুপারিশ করি।

1. ইস্যুয়ার সার্ভার: আমাদের উদাহরণ বাস্তবায়নে, আমাদের ইস্যুয়ার সার্ভার হল একটি Node.js সার্ভার যা ইস্যুয়ার HTTP এন্ডপয়েন্ট হোস্ট করার জন্য Express ফ্রেমওয়ার্ক ব্যবহার করে। আপনি GitHub-এ নমুনা কোডটি দেখতে পারেন।

2. টোকেন ইস্যুকারী: ইস্যুকারী ক্রিপ্টোগ্রাফিক কম্পোনেন্টের জন্য কোনও নির্দিষ্ট ভাষার প্রয়োজন হয় না তবে এই কম্পোনেন্টের পারফরম্যান্সের প্রয়োজনীয়তার কারণে, আমরা উদাহরণ হিসেবে একটি C বাস্তবায়ন প্রদান করছি, যা টোকেন পরিচালনা করার জন্য বোরিং SSL লাইব্রেরি ব্যবহার করে। আপনি ইস্যুকারী কোডের উদাহরণ এবং ইনস্টলেশন সম্পর্কে আরও তথ্য GitHub-এ খুঁজে পেতে পারেন।

3. কী: টোকেন ইস্যুকারী উপাদানটি টোকেন এনক্রিপ্ট করার জন্য কাস্টম EC কী ব্যবহার করে। এই কীগুলি সুরক্ষিত এবং নিরাপদ স্টোরেজে সংরক্ষণ করা আবশ্যক।

ইস্যুকারী সার্ভারের জন্য প্রযুক্তিগত প্রয়োজনীয়তা

প্রোটোকল অনুসারে, আপনার ইস্যুয়ার সার্ভারে কমপক্ষে দুটি HTTP এন্ডপয়েন্ট বাস্তবায়ন করতে হবে:

• কী-কমিটমেন্ট (উদাহরণস্বরূপ, /.well-known/private-state-token/key-commitment ): এই শেষ বিন্দুতে আপনার এনক্রিপশন পাবলিক কী বিবরণ ব্রাউজারগুলিতে উপলব্ধ থাকবে যাতে নিশ্চিত করা যায় যে আপনার সার্ভারটি বৈধ।
  • GitHub-এ কোড নমুনা
  • ডেমো দেখুন
• টোকেন ইস্যু (উদাহরণস্বরূপ, /.well-known/private-state-token/issuance ): টোকেন ইস্যু করার শেষ বিন্দু যেখানে সমস্ত টোকেন অনুরোধ পরিচালনা করা হবে। এই শেষ বিন্দুটি টোকেন ইস্যুকারী উপাদানের জন্য ইন্টিগ্রেশন পয়েন্ট হবে।
  • GitHub-এ কোড নমুনা
  • ডেমো দেখুন

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

ইস্যুকারী সার্ভারে একটি কল পাঠান

নতুন টোকেন ইস্যু করার জন্য আপনার ইস্যুকারী স্ট্যাকে একটি ওয়েবসাইট ফেচ কল বাস্তবায়ন করুন।

 // issuer request
    await fetch("/.well-known/private-state-token/issuance", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "token-request"
      }
    });

একটি কোড উদাহরণ দেখুন ।

রিডিমার সার্ভার

আপনার নিজস্ব সার্ভার-সাইড অ্যাপ্লিকেশন তৈরি করে টোকেন রিডেম্পশন পরিষেবাটি বাস্তবায়ন করতে হবে। এটি আপনাকে ইস্যুকারীর পাঠানো টোকেনগুলি পড়তে সাহায্য করবে। নিম্নলিখিত ধাপগুলি টোকেনগুলি কীভাবে রিডিম করবেন এবং সেই সাথে সেই টোকেনগুলির সাথে সম্পর্কিত রিডেম্পশন রেকর্ডগুলি কীভাবে পড়বেন তা বর্ণনা করে।

আপনি একই সার্ভারে (অথবা সার্ভারের গ্রুপে) ইস্যুকারী এবং রিডিমার চালানো বেছে নিতে পারেন।

রিডিমার সার্ভারের জন্য প্রযুক্তিগত প্রয়োজনীয়তা

প্রোটোকল অনুসারে, আপনার রিডিমার সার্ভারের জন্য কমপক্ষে দুটি HTTP এন্ডপয়েন্ট বাস্তবায়ন করতে হবে:

• /.well-known/private-state-token/redemption : এন্ডপয়েন্ট যেখানে সমস্ত টোকেন রিডেম্পশন পরিচালনা করা হবে। এই এন্ডপয়েন্টে টোকেন রিডিমার উপাদানটি একীভূত করা হবে
  • GitHub-এ উদাহরণ কোড
  • ডেমো

রিডিমার সার্ভারে একটি কল পাঠান

টোকেন রিডিম করার জন্য, আপনাকে আগে ইস্যু করা টোকেন রিডিম করার জন্য আপনার রিডিমার স্ট্যাকে একটি ওয়েবসাইট ফেচ কল বাস্তবায়ন করতে হবে।

    // redemption request
    await fetch("/.well-known/private-state-token/redemption", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "token-redemption",
        refreshPolicy: "none"
      }
    });

কোড নমুনা দেখুন।

একটি টোকেন রিডিম করার পর, আপনি আরেকটি ফেচ কল করে রিডিম্পশন রেকর্ড (RR) পাঠাতে পারেন:

    // attach redemption records from the issuers to the request
    await fetch("<DESTINATION_RESOURCE>", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "send-redemption-record",
        issuers: [<ISSUER_DOMAIN>]
      }
    });

কোড নমুনা দেখুন।

আপনার বাস্তবায়ন স্থাপন করুন

আপনার বাস্তবায়ন পরীক্ষা করার জন্য, প্রথমে সেই ওয়েব পৃষ্ঠায় যান যেখানে ইস্যু করা কল করা হয়েছে এবং নিশ্চিত করুন যে টোকেন(গুলি) আপনার যুক্তি অনুসারে তৈরি করা হয়েছে। আপনার ব্যাকএন্ডে যাচাই করুন যে কলগুলি স্পেসিফিকেশন অনুসারে করা হয়েছে। তারপর, সেই ওয়েব পৃষ্ঠায় যান যেখানে রিডিমিং কল করা হয়েছে এবং নিশ্চিত করুন যে RR গুলি তৈরি করা হয়েছে, আপনার যুক্তি অনুসারে।

বাস্তব বিশ্বের স্থাপনা

আমরা আপনাকে এমন ওয়েবসাইটগুলি বেছে নেওয়ার পরামর্শ দিচ্ছি যা আপনার নির্দিষ্ট ব্যবহারের ক্ষেত্রের অংশ:

• মাসিক ভিজিটের সংখ্যা কম (~ <1 মিলিয়ন ভিজিট/মাস): প্রথমে অল্প সংখ্যক দর্শকের কাছে API স্থাপন করে শুরু করা উচিত
• আপনি এটির মালিক এবং এটি নিয়ন্ত্রণ করেন: প্রয়োজনে আপনি জটিল অনুমোদন ছাড়াই দ্রুত বাস্তবায়ন বন্ধ করতে পারেন।
• একাধিক ইস্যুকারী নয়: পরীক্ষা সহজ করার জন্য টোকেনের পরিমাণ সীমিত করা।
• দুইজনের বেশি রিডিমার নয়: সমস্যার ক্ষেত্রে আপনাকে সমস্যা সমাধান সহজ করতে হবে।

অনুমতি নীতি

সঠিকভাবে কাজ করার জন্য, PST API অবশ্যই শীর্ষ-স্তরের পৃষ্ঠা এবং API ব্যবহারকারী যেকোনো উপ-সম্পদগুলিতে উপলব্ধ থাকতে হবে।

টোকেন-রিকোয়েস্ট অপারেশনটি private-state-token-issuance নির্দেশিকা দ্বারা নিয়ন্ত্রিত হয়। token-redemption এবং send-redemption-record অপারেশনগুলি private-state-token-redemption নির্দেশিকা দ্বারা নিয়ন্ত্রিত হয়। Chrome 132 এবং পরবর্তী সংস্করণগুলিতে, এই নির্দেশিকাগুলির জন্য অ্যালোলিস্টটি ডিফল্টরূপে * (সমস্ত অরিজিন) এ সেট করা আছে। এর অর্থ হল এই বৈশিষ্ট্যটি উচ্চ-স্তরের পৃষ্ঠা, একই-অরিজিন আইফ্রেম এবং ক্রস-অরিজিন আইফ্রেমে স্পষ্ট প্রতিনিধিত্ব ছাড়াই উপলব্ধ।

আপনার সাইটের নির্দিষ্ট পৃষ্ঠাগুলির জন্য PST টোকেন ইস্যু বা রিডেম্পশন থেকে বেরিয়ে আসতে, প্রতিটি পৃষ্ঠার জন্য Permissions-Policy হেডারে private-state-token-issuance=() এবং private-state-token-redemption=() অন্তর্ভুক্ত করতে পারেন।

আপনি PST-তে তৃতীয় পক্ষের অ্যাক্সেস নিয়ন্ত্রণ করতে Permissions-Policy হেডার ব্যবহার করতে পারেন। হেডার অরিজিন তালিকার প্যারামিটার হিসেবে, self এবং API-তে অ্যাক্সেসের অনুমতি দিতে চান এমন যেকোনো অরিজিন ব্যবহার করুন। উদাহরণস্বরূপ, আপনার নিজস্ব অরিজিন এবং https://example.com ব্যতীত সকল ব্রাউজিং প্রসঙ্গে PST-এর ব্যবহার সম্পূর্ণরূপে বন্ধ করতে, নিম্নলিখিত HTTP প্রতিক্রিয়া হেডারগুলি সেট করুন:

Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")

সমস্ত ক্রস-অরিজিন রিসোর্সের জন্য API সক্ষম করতে, অরিজিন তালিকাটি * তে সেট করুন।

অনুমতি নীতি ব্যবহার করে গোপনীয়তা স্যান্ডবক্স বৈশিষ্ট্যগুলি কীভাবে নিয়ন্ত্রণ করবেন তা শিখুন অথবা অনুমতি নীতি সম্পর্কে আরও গভীরভাবে জানুন।

সমস্যা সমাধান

আপনি Chrome DevTools নেটওয়ার্ক এবং অ্যাপ্লিকেশন ট্যাব থেকে PST গুলি পরিদর্শন করতে পারেন।

নেটওয়ার্ক ট্যাবে:

অ্যাপ্লিকেশন ট্যাবে:

এই DevTools ইন্টিগ্রেশন সম্পর্কে আরও পড়ুন।

ক্লায়েন্টের সেরা অনুশীলন

যদি আপনার ওয়েবসাইটের গুরুত্বপূর্ণ ফাংশনগুলি নির্দিষ্ট টোকেন ইস্যুকারীর উপর নির্ভর করে, তাহলে তাদের অগ্রাধিকার দিন। অন্য কোনও স্ক্রিপ্ট লোড করার আগে এই পছন্দের ইস্যুকারীর জন্য hasPrivateToken(issuer) কল করুন। সম্ভাব্য রিডেম্পশন ব্যর্থতা রোধ করার জন্য এটি অত্যন্ত গুরুত্বপূর্ণ।

প্রতি শীর্ষ-স্তরের ইস্যুকারীর সংখ্যা দুইজনের মধ্যে সীমাবদ্ধ , এবং তৃতীয় পক্ষের স্ক্রিপ্টগুলি তাদের পছন্দের ইস্যুকারীকে অগ্রাধিকার দেওয়ার জন্য hasPrivateToken(issuer) কল করার চেষ্টা করতে পারে। তাই, আপনার সাইটটি প্রত্যাশা অনুযায়ী কাজ করছে কিনা তা নিশ্চিত করার জন্য আপনার প্রয়োজনীয় ইস্যুকারীকে আগে থেকেই নিশ্চিত করুন।

  // Prioritize your critical token issuer.
  document.hasPrivateToken('https://critical-issuer.example')
    .then(hasToken => {
      if (hasToken) {
        // Use the token or perform actions based on its availability.
      } else {
        // Handle the case where the token is not available.
      }
    });

  // Load third-party scripts or secure another token issuer (up to two in total).

সার্ভারের সেরা অনুশীলন এবং সমস্যা সমাধান

আপনার ইস্যুকারী এবং রিডিমার সার্ভার কার্যকরভাবে পরিচালনা করার জন্য, আমরা নিম্নলিখিত সেরা অনুশীলনগুলি বাস্তবায়নের পরামর্শ দিচ্ছি যাতে আপনি PST-এর জন্য কোনও অ্যাক্সেস, সুরক্ষা, লগিং বা ট্র্যাফিক চ্যালেঞ্জের সম্মুখীন না হন।

• আপনার এন্ডপয়েন্টগুলিকে TLS 1.3 বা 1.2 ব্যবহার করে শক্তিশালী ক্রিপ্টোগ্রাফি প্রয়োগ করতে হবে।
• আপনার অবকাঠামোকে পরিবর্তনশীল ট্র্যাফিক ভলিউম (স্পাইক সহ) পরিচালনা করার জন্য প্রস্তুত থাকতে হবে।
• নিশ্চিত করুন যে আপনার চাবিগুলি সুরক্ষিত এবং সুরক্ষিত, আপনার অ্যাক্সেস নিয়ন্ত্রণ নীতি, চাবি ব্যবস্থাপনা কৌশল এবং ব্যবসায়িক ধারাবাহিকতা পরিকল্পনার সাথে সামঞ্জস্যপূর্ণ।
• উৎপাদনে যাওয়ার পরে ব্যবহার, বাধা এবং কর্মক্ষমতা সংক্রান্ত সমস্যাগুলি বোঝার জন্য আপনার দৃশ্যমানতা নিশ্চিত করতে আপনার স্ট্যাকে পর্যবেক্ষণযোগ্যতা মেট্রিক্স যুক্ত করুন।

অধিক তথ্য

1. ডেভেলপার ডকুমেন্ট পর্যালোচনা করুন:
   1. PST এবং এর ক্ষমতা সম্পর্কে দ্রুত জানতে সারসংক্ষেপটি পড়ে শুরু করুন।
   2. PST ভূমিকা ভিডিওটি দেখুন।
   3. PST ডেমোটি চেষ্টা করে দেখুন।
   4. এ সম্পর্কে আরও বিস্তারিত জানতে API ব্যাখ্যাকারীটিও পড়ুন।
   5. API এর বর্তমান স্পেসিফিকেশন সম্পর্কে আরও পড়ুন।
2. GitHub সমস্যা বা W3C কল ব্যবহার করে কথোপকথনে অবদান রাখুন।
3. যেকোনো পরিভাষা আরও ভালোভাবে বুঝতে, প্রাইভেসি স্যান্ডবক্স শব্দকোষটি পর্যালোচনা করুন।
4. 'অরিজিন ট্রায়াল' বা 'ক্রোম ফ্ল্যাগস'-এর মতো Chrome ধারণা সম্পর্কে আরও জানতে, goo.gle/cc ওয়েবসাইটে উপলব্ধ ছোট ভিডিও এবং নিবন্ধগুলি পর্যালোচনা করুন।