অতীতে, তৃতীয় পক্ষের কুকিগুলি ব্যবহারকারীর অবস্থা, যেমন তাদের সাইন-ইন স্থিতি, তারা যে ডিভাইসটি ব্যবহার করছে সে সম্পর্কে তথ্য বা তারা পরিচিত এবং বিশ্বস্ত কিনা সে সম্পর্কে তথ্য সংরক্ষণ এবং জানাতে ব্যবহার করা হয়েছে৷ উদাহরণস্বরূপ, ব্যবহারকারী SSO এর সাথে লগ ইন করেছেন কিনা, ব্যবহারকারীর একটি নির্দিষ্ট ধরণের সামঞ্জস্যপূর্ণ ডিভাইস আছে কিনা বা ব্যবহারকারী পরিচিত এবং বিশ্বস্ত কিনা। তৃতীয় পক্ষের কুকি সমর্থন অবমূল্যায়িত হওয়ার সাথে সাথে, এই ব্যবহারের ক্ষেত্রে অনেকগুলি অন্যান্য উপায়ে সমর্থন করা প্রয়োজন।
প্রাইভেট স্টেট টোকেনগুলি ওয়েব জুড়ে তথ্য ভাগ করার একটি উপায় অফার করে, কিন্তু প্রকৃতপক্ষে ভাগ করা যেতে পারে এমন ডেটার পরিমাণ নিয়ন্ত্রণের মাধ্যমে গোপনীয়তা-সংরক্ষণের উপায়ে।
প্রাইভেট স্টেট টোকেন (পূর্বে ট্রাস্ট টোকেন নামে পরিচিত) ব্যবহারকারীর সত্যতার উপর বিশ্বাসকে এক প্রসঙ্গ থেকে অন্য প্রসঙ্গে জানানোর অনুমতি দেয় যখন সাইটগুলিকে প্রতারণার বিরুদ্ধে লড়াই করতে এবং বটগুলিকে প্রকৃত মানুষের থেকে আলাদা করতে সাহায্য করে—প্যাসিভ ট্র্যাকিং ছাড়াই৷
এই নথিটি প্রাইভেট স্টেট টোকেন (PST) বাস্তবায়নের জন্য প্রযুক্তিগত বিবরণের রূপরেখা দেয়। আরও উচ্চ-স্তরের রূপরেখার জন্য, PST ওভারভিউ দেখুন।
প্রাইভেট স্টেট টোকেন কিভাবে কাজ করে?
PST-এ বোঝার মূল সম্পর্ক হল ইস্যুকারী এবং রিডিমারদের মধ্যে। ইস্যুকারী এবং রিডিমার একই কোম্পানির মধ্যে হতে পারে।
- ইস্যুকারী - এই সত্ত্বাগুলির একটি ব্যবহারকারী সম্পর্কে কিছু সংকেত রয়েছে (উদাহরণস্বরূপ, সেই ব্যবহারকারী একজন বট হোক বা না হোক) এবং ব্যবহারকারীর ডিভাইসে সংরক্ষিত একটি টোকেনে সেই সংকেত এম্বেড করে (পরবর্তী বিভাগে আরও বিশদ বিবরণ)।
- রিডিমার - এই সত্ত্বাগুলির কোনও ব্যবহারকারী সম্পর্কে কোনও সংকেত নাও থাকতে পারে তবে তাদের সম্পর্কে কিছু জানতে হবে (উদাহরণস্বরূপ, সেই ব্যবহারকারী একজন বট কিনা) এবং সেই ব্যবহারকারীর বিশ্বস্ততা বোঝার জন্য ইস্যুকারীর কাছ থেকে একটি টোকেন রিডিম করতে বলুন৷
প্রতিটি PST ইন্টারঅ্যাকশনের জন্য ইস্যুকারী এবং রিডিমারকে ওয়েব জুড়ে সংকেত ভাগ করার জন্য একসাথে কাজ করতে হবে। এই সংকেতগুলি মোটা মান যা ব্যক্তিদের সনাক্ত করার জন্য যথেষ্ট বিস্তারিত নয়।
ব্যক্তিগত রাষ্ট্রীয় টোকেন কি আমার জন্য সঠিক?
যে কোম্পানিগুলি আস্থার সিদ্ধান্ত নিচ্ছে এবং সেই তথ্যগুলি প্রেক্ষাপট জুড়ে উপলব্ধ হতে চায় তারা PST থেকে উপকৃত হতে পারে। PST-এর সম্ভাব্য ব্যবহারের ক্ষেত্রে আরও জানতে, PST ব্যবহারের ক্ষেত্রে আমাদের ডকুমেন্টেশন দেখুন।
টোকেন ইস্যু এবং রিডিম করুন
PST বাস্তবায়ন তিনটি পর্যায়ে ঘটে:
- টোকেন প্রদান
- টোকেন রিডিম করা হচ্ছে
- রিডেম্পশন রেকর্ড ফরওয়ার্ডিং
প্রথম পর্যায়ে, একটি ব্রাউজারে টোকেন জারি করা হয় (সাধারণত কিছু ধরণের বৈধতার পরে)। দ্বিতীয় পর্যায়ে, অন্য একটি সত্তা সেই টোকেনের মান পড়ার জন্য জারি করা টোকেনটি রিডিম করার জন্য অনুরোধ করবে। চূড়ান্ত পর্যায়ে, রিডিমিং পার্টি টোকেনে থাকা মান সহ একটি রিডেম্পশন রেকর্ড (RR) পায়। সেই রিডিমিং পার্টি সেই রেকর্ডটিকে বিভিন্ন উদ্দেশ্যে সেই ব্যবহারকারীর প্রত্যয়ন হিসাবে ব্যবহার করতে পারে৷
আপনার টোকেন কৌশল নির্ধারণ করুন
আপনার টোকেন কৌশল সংজ্ঞায়িত করার জন্য, আপনাকে PST মূল ধারণাগুলি (টোকেন এবং রিডেম্পশন রেকর্ড), ভেরিয়েবল, আচরণ এবং সীমাবদ্ধতাগুলি আপনার ব্যবহারের ক্ষেত্রে তাদের সম্ভাব্য ব্যবহার সম্পর্কে চিন্তা করতে সক্ষম হতে হবে।
টোকেন এবং রিডেম্পশন রেকর্ড: তাদের মধ্যে সম্পর্ক কি?
প্রতিটি ডিভাইস শীর্ষ-স্তরের ওয়েবসাইট এবং ইস্যুকারী প্রতি 500 টোকেন পর্যন্ত সঞ্চয় করতে পারে। এছাড়াও, প্রতিটি টোকেনের মেটাডেটা থাকে যা ইস্যুকারী কোন কী ব্যবহার করে তা জানিয়ে দেয়। সেই তথ্যটি রিডিম করার প্রক্রিয়া চলাকালীন টোকেন রিডিম করা বা না করার সিদ্ধান্ত নিতে ব্যবহার করা যেতে পারে। PST ডেটা ব্যবহারকারীর ডিভাইসে ব্রাউজার দ্বারা অভ্যন্তরীণভাবে সংরক্ষণ করা হয় এবং শুধুমাত্র PST API দ্বারা অ্যাক্সেস করা যেতে পারে।
যখন একটি টোকেন রিডিম করা হয়, তখন রিডেম্পশন রেকর্ড (RR) ডিভাইসে সংরক্ষণ করা হয়। এই স্টোরেজ ভবিষ্যত রিডেম্পশনের জন্য ক্যাশে হিসেবে কাজ করে। ডিভাইস, পৃষ্ঠা এবং ইস্যুকারী প্রতি 48 ঘণ্টায় দুটি টোকেন রিডিম্পশনের একটি সীমা রয়েছে। নতুন রিডেম্পশন কলগুলি ইস্যুকারীর কাছে অনুরোধ না করে যেখানে সম্ভব সেখানে ক্যাশে করা RR ব্যবহার করবে।
- নতুন টোকেন ইস্যু করা হয় (ইস্যুকারী, সাইট এবং ডিভাইস প্রতি সর্বোচ্চ 500)।
- সমস্ত টোকেন ডিভাইসে টোকেন স্টোরে (কুকি স্টোরের মতো) সংরক্ষণ করা হয়।
- যদি কোনো সক্রিয় RR পাওয়া না যায়, তাহলে ইস্যু করার পরে নতুন RR তৈরি করা যেতে পারে (প্রতি 48 ঘণ্টায় সর্বোচ্চ 2টি)।
- মেয়াদ শেষ না হওয়া পর্যন্ত RRs সক্রিয় বলে বিবেচিত হয় এবং সেগুলি স্থানীয় ক্যাশে হিসাবে ব্যবহার করা হবে।
- নতুন রিডেম্পশন কল স্থানীয় ক্যাশে আঘাত করবে (কোনও নতুন RR তৈরি হয় না)।
আপনার ব্যবহারের ক্ষেত্রে সংজ্ঞায়িত করার পরে, আপনাকে অবশ্যই আপনার RR-এর জীবনকাল সাবধানে সংজ্ঞায়িত করতে হবে কারণ এটি আপনার ক্ষেত্রে কতবার ব্যবহার করতে পারবে তা নির্ধারণ করবে।
আপনার কৌশল সংজ্ঞায়িত করার আগে আপনি নিম্নলিখিত সমালোচনামূলক আচরণ এবং ভেরিয়েবলগুলি বুঝতে পেরেছেন তা নিশ্চিত করুন:
| পরিবর্তনশীল/আচরণ | বর্ণনা | সম্ভাব্য ব্যবহার |
|---|---|---|
| টোকেন কী মেটাডেটা | প্রতিটি টোকেন একটি এবং শুধুমাত্র একটি ক্রিপ্টোগ্রাফিক কী ব্যবহার করে জারি করা যেতে পারে এবং PST-তে প্রতি ইস্যুকারীর জন্য ছয়টি কী-র সীমাবদ্ধতা রয়েছে। | এই ভেরিয়েবলটি ব্যবহার করার একটি সম্ভাব্য উপায় হল আপনার ক্রিপ্টোগ্রাফিক কীগুলির উপর ভিত্তি করে আপনার টোকেনগুলিতে বিশ্বাসের একটি পরিসীমা সংজ্ঞায়িত করা (উদাহরণস্বরূপ, কী 1 = উচ্চ বিশ্বাস যখন কী 6 = কোন বিশ্বাস নেই)। |
| টোকেনের মেয়াদ শেষ হওয়ার তারিখ | টোকেনের মেয়াদ শেষ হওয়ার তারিখ কী মেয়াদ শেষ হওয়ার তারিখের মতোই। | কীগুলি কমপক্ষে প্রতি 60 দিনে ঘোরানো যেতে পারে এবং অবৈধ কীগুলির সাথে জারি করা সমস্ত টোকেনও অবৈধ বলে বিবেচিত হয়৷ |
| টোকেন রিডেম্পশন রেট সীমা | প্রতি 48 ঘন্টায় প্রতি ডিভাইস এবং ইস্যুকারীর জন্য দুটি টোকেন রিডেম্পশনের সীমা রয়েছে। | প্রতি 48 ঘন্টায় আপনার ব্যবহারের ক্ষেত্রে প্রয়োজনীয় রিডিমশনের আনুমানিক সংখ্যার উপর নির্ভর করে। |
| শীর্ষ স্তরের মূল প্রতি ইস্যুকারীর সর্বাধিক সংখ্যা | শীর্ষ স্তরের প্রতি ইস্যুকারীর সর্বাধিক সংখ্যা বর্তমানে দুইজন। | প্রতিটি পৃষ্ঠার ইস্যুকারীকে সাবধানে সংজ্ঞায়িত করুন। |
| একটি ডিভাইসে ইস্যুকারী প্রতি টোকেন | একটি নির্দিষ্ট ডিভাইসে ইস্যুকারী প্রতি টোকেনের সর্বাধিক সংখ্যা বর্তমানে 500। | ইস্যুকারী প্রতি টোকেনের সংখ্যা 500-এর কম রাখতে ভুলবেন না। টোকেন ইস্যু করার চেষ্টা করার সময় আপনার ওয়েব পৃষ্ঠায় ত্রুটিগুলি পরিচালনা করা নিশ্চিত করুন৷ |
| মূল প্রতিশ্রুতি ঘূর্ণন | প্রতিটি PST ইস্যুকারীকে মূল প্রতিশ্রুতি সহ একটি শেষ পয়েন্ট প্রকাশ করতে হবে যা প্রতি 60 দিনে পরিবর্তিত হতে পারে এবং এর চেয়ে দ্রুত যে কোনও ঘূর্ণন উপেক্ষা করা হবে। | যদি আপনার কীগুলির মেয়াদ 60 দিনেরও কম সময়ের মধ্যে শেষ হতে চলেছে, তবে বিঘ্ন এড়াতে সেই তারিখের আগে আপনার মূল প্রতিশ্রুতিগুলি আপডেট করা বাধ্যতামূলক ( বিশদ বিবরণ দেখুন)৷ |
| খালাস রেকর্ড জীবনকাল | মেয়াদ শেষ হওয়ার তারিখ নির্ধারণ করার জন্য RR এর জীবনকাল সংজ্ঞায়িত করা যেতে পারে। যেহেতু ইস্যুকারীর কাছে অপ্রয়োজনীয় নতুন রিডেম্পশন কল এড়াতে RRগুলি ক্যাশ করা হয়, তাই যথেষ্ট তাজা রিডেম্পশন সিগন্যাল আছে তা নিশ্চিত করা গুরুত্বপূর্ণ। | যেহেতু প্রতি 48 ঘণ্টায় দুটি টোকেনের রিডেম্পশন রেট-সীমা রয়েছে, তাই অন্তত এই সময়ের মধ্যে সফলতার সাথে রিডেম্পশন কলগুলি সম্পাদন করতে সক্ষম হওয়ার জন্য আপনার RR-এর জীবনকাল নির্ধারণ করা গুরুত্বপূর্ণ (RR জীবনকাল সেই অনুযায়ী সেট করা উচিত)। সপ্তাহের ক্রম অনুসারে এই জীবনকাল সেট করার সুপারিশ করা হয়। |
উদাহরণ দৃশ্যকল্প
পরিস্থিতি #1: RR আয়ুষ্কাল 24 ঘন্টার কম (t=t) এবং 48-ঘন্টার উইন্ডোতে একাধিকবার রিডেম্পশন করা হয়।
দৃশ্যকল্প #2: RR জীবনকাল 24 ঘন্টা এবং 48-ঘন্টার উইন্ডোতে একাধিকবার রিডেম্পশন করা হয়।
দৃশ্যকল্প #3: RR আয়ুষ্কাল 48 ঘন্টা এবং রিডেম্পশন 48 ঘন্টার উইন্ডোতে একাধিকবার সঞ্চালিত হয়।
ডেমো চালান
PST গ্রহণ করার আগে, আমরা প্রথমে ডেমো দিয়ে সেট আপ করার পরামর্শ দিই। PST ডেমো ব্যবহার করে দেখতে, আপনাকে ডেমো ইস্যুকারী কী প্রতিশ্রুতিগুলি সক্ষম করতে পতাকা সহ Chrome চালাতে হবে ( ডেমো পৃষ্ঠায় উপলব্ধ নির্দেশাবলী অনুসরণ করুন)।
এই ডেমো চালানোর মাধ্যমে, আপনার ব্রাউজার টোকেন প্রদান এবং ব্যবহার করতে ডেমো প্রদানকারী এবং রিডিমার সার্ভার ব্যবহার করছে।
প্রযুক্তিগত বিবেচনা
আপনি নিম্নলিখিত পদক্ষেপগুলি বাস্তবায়ন করলে ডেমোটি সর্বোত্তমভাবে চলবে:
- পতাকা সহ Chrome চালানোর আগে নিশ্চিত করুন যে আপনি সমস্ত ক্রোম দৃষ্টান্ত বন্ধ করেছেন৷
- আপনি যদি একটি উইন্ডোজ মেশিনে চালান, তাহলে Chrome এক্সিকিউটেবল বাইনারিতে প্যারামিটারগুলি কীভাবে পাস করবেন সে সম্পর্কে এই নির্দেশিকাটি দেখুন।
- ডেমো অ্যাপ্লিকেশান ব্যবহার করার সময় অ্যাপ্লিকেশন > স্টোরেজ > প্রাইভেট স্টেট টোকেনের অধীনে Chrome DevTools খুলুন ডেমো ইস্যুকারীর দ্বারা ইস্যু করা/রিডিম করা টোকেনগুলি দেখতে।
দত্তক জন্য সেট আপ
ইস্যুকারী হয়ে উঠুন
ইস্যুকারীরা PST-তে গুরুত্বপূর্ণ ভূমিকা পালন করে। ব্যবহারকারী বট কিনা তা নির্ধারণ করতে তারা টোকেনগুলিতে মান নির্ধারণ করে। আপনি যদি একটি ইস্যুকারী হিসাবে PST এর সাথে শুরু করতে চান, তাহলে আপনাকে ইস্যুকারী নিবন্ধন প্রক্রিয়াটি সম্পূর্ণ করে নিবন্ধন করতে হবে।
ইস্যুকারী হওয়ার জন্য আবেদন করতে, ইস্যুকারী ওয়েবসাইটের অপারেটরকে অবশ্যই "নতুন PST ইস্যুয়ার" টেমপ্লেট ব্যবহার করে GitHub সংগ্রহস্থলে একটি নতুন সমস্যা খুলতে হবে। সমস্যাটি পূরণ করতে সংগ্রহস্থলের নির্দেশিকা অনুসরণ করুন। একবার একটি এন্ডপয়েন্ট যাচাই করা হয়ে গেলে, এটি এই সংগ্রহস্থলে একত্রিত হবে এবং Chrome সার্ভার-সাইড অবকাঠামো সেই কীগুলি আনা শুরু করবে৷
ইস্যুকারী সার্ভার
ইস্যুকারী এবং রিডিমাররা হল PST-এর মূল অভিনেতা; সার্ভার এবং টোকেন হল PST-এর মূল টুল। যদিও আমরা ইতিমধ্যে টোকেন এবং গিথুব ডকুমেন্টেশনে কিছু বিশদ প্রদান করেছি, আমরা PST সার্ভারগুলিতে আরও বিশদ বিবরণ দিতে চেয়েছিলাম। PST এর ইস্যুকারী হিসাবে সেট আপ করার জন্য, আপনাকে প্রথমে একটি ইস্যুকারী সার্ভার সেট আপ করতে হবে।
আপনার পরিবেশ স্থাপন করুন: ইস্যুকারী সার্ভার
টোকেন ইস্যুকারী সার্ভার বাস্তবায়ন করার জন্য আপনাকে HTTP এন্ডপয়েন্ট প্রকাশ করে আপনার নিজস্ব সার্ভার সাইড অ্যাপ্লিকেশন তৈরি করতে হবে।
ইস্যুকারী উপাদান দুটি প্রধান মডিউল নিয়ে গঠিত: (1) ইস্যুকারী সার্ভার এবং (2) টোকেন প্রদানকারী।
সমস্ত ওয়েব-মুখী অ্যাপ্লিকেশনগুলির মতো, আমরা আপনার ইস্যুকারী সার্ভারে সুরক্ষার একটি অতিরিক্ত স্তর সুপারিশ করি৷
ইস্যুকারী সার্ভার: আমাদের উদাহরণ বাস্তবায়নে, আমাদের ইস্যুকারী সার্ভার হল একটি Node.js সার্ভার যা ইস্যুকারী HTTP এন্ডপয়েন্ট হোস্ট করতে এক্সপ্রেস ফ্রেমওয়ার্ক ব্যবহার করে। আপনি GitHub এ নমুনা কোড পরীক্ষা করতে পারেন।
টোকেন ইস্যুকারী: ইস্যুকারী ক্রিপ্টোগ্রাফিক উপাদানটির জন্য কোনো নির্দিষ্ট ভাষার প্রয়োজন নেই কিন্তু এই উপাদানটির কার্যক্ষমতার প্রয়োজনীয়তার কারণে, আমরা উদাহরণ হিসেবে একটি C বাস্তবায়ন প্রদান করছি, যা টোকেন পরিচালনা করতে বোরিং SSL লাইব্রেরি ব্যবহার করে। আপনি ইস্যুকারী কোডের উদাহরণ এবং GitHub এ ইনস্টলেশন সম্পর্কে আরও তথ্য পেতে পারেন
কী: টোকেন ইস্যুকারী উপাদান টোকেন এনক্রিপ্ট করতে কাস্টম ইসি কী ব্যবহার করে। এই কীগুলি অবশ্যই সুরক্ষিত রাখতে হবে এবং সুরক্ষিত স্টোরেজে সংরক্ষণ করতে হবে।
ইস্যুকারী সার্ভারের জন্য প্রযুক্তিগত প্রয়োজনীয়তা
প্রোটোকল অনুসারে, আপনাকে আপনার ইস্যুকারী সার্ভারে কমপক্ষে দুটি HTTP শেষ পয়েন্ট প্রয়োগ করতে হবে:
- কী-প্রতিশ্রুতি (উদাহরণস্বরূপ,
/.well-known/private-state-token/key-commitment): এই শেষ পয়েন্ট যেখানে আপনার এনক্রিপশন পাবলিক কী বিশদ ব্রাউজারগুলিতে উপলব্ধ হবে আপনার সার্ভার বৈধ কিনা তা নিশ্চিত করতে। - টোকেন ইস্যু (উদাহরণস্বরূপ,
/.well-known/private-state-token/issuance): টোকেন ইস্যু করার শেষ পয়েন্ট যেখানে সমস্ত টোকেন অনুরোধ পরিচালনা করা হবে। এই শেষ পয়েন্টটি টোকেন ইস্যুকারী উপাদানের জন্য ইন্টিগ্রেশন পয়েন্ট হবে।
পূর্বে উল্লিখিত হিসাবে, প্রত্যাশিত উচ্চ ট্র্যাফিকের কারণে এই সার্ভারটি সম্ভাব্যভাবে পরিচালনা করবে, আমরা আপনাকে পরিবর্তনশীল চাহিদার উপর ভিত্তি করে আপনার ব্যাকএন্ড সামঞ্জস্য করতে সক্ষম হওয়ার জন্য একটি পরিমাপযোগ্য পরিকাঠামো (উদাহরণস্বরূপ, একটি ক্লাউড পরিবেশে) ব্যবহার করে এটি স্থাপন করার পরামর্শ দিই।
ইস্যুকারী সার্ভারে একটি কল পাঠান
নতুন টোকেন ইস্যু করার জন্য আপনার ইস্যুকারী স্ট্যাকে একটি ওয়েবসাইট আনয়ন কল প্রয়োগ করুন।
// 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: শেষ পয়েন্ট যেখানে সমস্ত টোকেন রিডেম্পশন পরিচালনা করা হবে। এই এন্ডপয়েন্টটি হবে যেখানে টোকেন রিডিমার কম্পোনেন্ট ইন্টিগ্রেট করা হবে
রিডিমার সার্ভারে একটি কল পাঠান
টোকেন রিডিম করার জন্য, আগে জারি করা টোকেন রিডিম করার জন্য আপনাকে আপনার রিডিমার স্ট্যাকে একটি ওয়েবসাইট ফেচ কল প্রয়োগ করতে হবে।
// 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 এবং পরবর্তীতে, এই নির্দেশাবলীর জন্য অনুমোদিত তালিকা ডিফল্টরূপে * (সমস্ত মূল) সেট করা আছে। এর মানে হল যে বৈশিষ্ট্যটি শীর্ষ-স্তরের পৃষ্ঠা, একই-অরিজিন আইফ্রেম এবং ক্রস-অরিজিন আইফ্রেমগুলিতে স্পষ্ট প্রতিনিধিত্ব ছাড়াই উপলব্ধ।
আপনি প্রতিটি পৃষ্ঠার অনুমতি-নীতি শিরোনামে private-state-token-issuance=() এবং private-state-token-redemption=() অন্তর্ভুক্ত করে আপনার সাইটের নির্দিষ্ট পৃষ্ঠাগুলির জন্য PST টোকেন ইস্যু বা রিডেম্পশন অপ্ট আউট করতে পারেন।
আপনি 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 ব্যবহার করে আপনার এন্ডপয়েন্টকে শক্তিশালী ক্রিপ্টোগ্রাফি প্রয়োগ করতে হবে।
- পরিবর্তনশীল ট্রাফিক ভলিউম (স্পাইক সহ) পরিচালনা করার জন্য আপনার পরিকাঠামো অবশ্যই প্রস্তুত হতে হবে।
- নিশ্চিত করুন যে আপনার কীগুলি সুরক্ষিত এবং সুরক্ষিত, আপনার অ্যাক্সেস কন্ট্রোল পলিসি, কী ম্যানেজমেন্ট স্ট্র্যাটেজি এবং ব্যবসায়িক ধারাবাহিকতা পরিকল্পনার সাথে সারিবদ্ধ।
- প্রোডাকশনে যাওয়ার পরে ব্যবহার, প্রতিবন্ধকতা এবং পারফরম্যান্সের সমস্যাগুলি বোঝার জন্য আপনার কাছে দৃশ্যমানতা রয়েছে তা নিশ্চিত করতে আপনার স্ট্যাকে পর্যবেক্ষণযোগ্যতা মেট্রিক্স যুক্ত করুন।
আরও তথ্য
- বিকাশকারী ডক্স পর্যালোচনা করুন:
- PST এবং এর ক্ষমতার সাথে গতি পেতে ওভারভিউ পড়ে শুরু করুন।
- PST ভূমিকা ভিডিও দেখুন।
- PST ডেমো ব্যবহার করে দেখুন।
- এছাড়াও এটি সম্পর্কে আরও বিশদ বুঝতে API ব্যাখ্যাকারী পড়ুন।
- API এর বর্তমান স্পেস সম্পর্কে আরও পড়ুন।
- GitHub সমস্যা বা W3C কলের মাধ্যমে কথোপকথনে অবদান রাখুন।
- যেকোনও পরিভাষা ভালোভাবে বুঝতে, গোপনীয়তা স্যান্ডবক্স শব্দকোষ পর্যালোচনা করুন।
- 'অরিজিন ট্রায়াল' বা 'Chrome পতাকা'-এর মতো Chrome ধারণা সম্পর্কে আরও জানতে, goo.gle/cc থেকে উপলব্ধ ছোট ভিডিও এবং নিবন্ধগুলি পর্যালোচনা করুন৷