ক্রোম ১৩০ সংস্করণে স্টোরেজ অ্যাক্সেস API (SAA) তে HTTP হেডার যুক্ত করার জন্য একটি অরিজিন ট্রায়াল শুরু করছে: স্টোরেজ অ্যাক্সেস হেডার । নতুন Sec-Fetch-Storage-Access অনুরোধ হেডার এবং Activate-Storage-Access প্রতিক্রিয়া হেডারের লক্ষ্য হল নন-আইফ্রেম রিসোর্সগুলিকে সমর্থন করা, এবং সোশ্যাল মিডিয়া উইজেট, ক্যালেন্ডার এবং ইন্টারেক্টিভ টুলের মতো এমবেডেড কন্টেন্টের উপর নির্ভরশীল ওয়েবসাইটগুলির কর্মক্ষমতা এবং ব্যবহারকারীর অভিজ্ঞতা উন্নত করা।
জাভাস্ক্রিপ্ট প্রবাহ (এবং এর সীমাবদ্ধতা)
পূর্বে, SAA-এর জন্য প্রতিটি রিলোডের সময় document.requestStorageAccess() তে একটি JavaScript API কল প্রয়োজন হত, এমনকি ব্যবহারকারী ইতিমধ্যেই অনুমতি দিলেও। কার্যকর হলেও, এই পদ্ধতিটি সীমাবদ্ধতাগুলি প্রবর্তন করে:
- একাধিক নেটওয়ার্ক রাউন্ড ট্রিপ: এম্বেডেড কন্টেন্ট সম্পূর্ণরূপে কাজ করার আগে এই প্রক্রিয়াটিতে প্রায়শই বেশ কয়েকটি নেটওয়ার্ক অনুরোধ এবং পৃষ্ঠা পুনরায় লোড করা জড়িত ছিল।
- আইফ্রেম নির্ভরতা: জাভাস্ক্রিপ্ট এক্সিকিউশনের ফলে আইফ্রেমের মধ্যে আইফ্রেম বা সাবরিসোর্সের ব্যবহার বাধ্যতামূলক করা হয়েছিল, যা ডেভেলপারদের জন্য নমনীয়তা সীমিত করেছিল।
উদাহরণস্বরূপ, শুধুমাত্র জাভাস্ক্রিপ্ট ব্যবহার করে website.example এ এমবেড করা calendar.example থেকে একটি ক্যালেন্ডার উইজেট দেখতে এরকম হবে:
- একটি স্থানধারক লোড করুন:
website.exampleউইজেটটি অনুরোধ করে। যেহেতুwebsite.exampleএ এমবেড করাcalendar.exampleউইজেটের তার অ-পার্টিশনযুক্ত কুকিতে অ্যাক্সেস নেই, তাই পরিবর্তে একটি স্থানধারক উইজেট রেন্ডার করা হয়। - অনুমতির অনুরোধ: প্লেসহোল্ডার লোড হয়, তারপর
document.requestStorageAccess()কে কল করেstorage-accessঅনুমতির অনুরোধ করে। - ব্যবহারকারী অনুমতি প্রদান করতে পছন্দ করেন ।
- উইজেটটি পুনরায় লোড করুন: উইজেটটি রিফ্রেশ হয়, এবার কুকি অ্যাক্সেস সহ, এবং অবশেষে ব্যক্তিগতকৃত সামগ্রী লোড করে।
- প্রতিবার যখন ব্যবহারকারী
calendar.exampleউইজেটটি আবার এম্বেড করে কোনও সাইটে যান, তখন প্রবাহটি ধাপ ১, ২ এবং ৪ এর মতোই দেখায়; একমাত্র সরলীকরণ হল ব্যবহারকারীকে পুনরায় অ্যাক্সেস দেওয়ার প্রয়োজন নেই।
এই প্রবাহটি অদক্ষ: যদি ব্যবহারকারী ইতিমধ্যেই স্টোরেজ অনুমতি দিয়ে থাকেন, তাহলে প্রাথমিক আইফ্রেম লোড, document.requestStorageAccess() কল এবং পরবর্তী রিলোড অপ্রয়োজনীয় হয়ে পড়ে এবং ল্যাটেন্সি তৈরি করে।
HTTP হেডার সহ নতুন প্রবাহ
নতুন স্টোরেজ অ্যাক্সেস হেডারগুলি নন-আইফ্রেম রিসোর্স সহ এমবেডেড কন্টেন্টের আরও দক্ষ লোডিং সক্ষম করে।
স্টোরেজ অ্যাক্সেস হেডারের সাহায্যে, ব্যবহারকারী যদি ইতিমধ্যেই অনুমতি দিয়ে থাকেন, তাহলে ব্রাউজারটি স্বয়ংক্রিয়ভাবে Sec-Fetch-Storage-Access: inactive অনুরোধ হেডার সেট সহ রিসোর্সগুলি আনবে। অনুরোধ হেডার সেট করার জন্য কোনও ডেভেলপার পদক্ষেপের প্রয়োজন নেই। সার্ভারটি Activate-Storage-Access: retry; allowed-origin="<origin>" হেডার দিয়ে প্রতিক্রিয়া জানাতে পারে এবং ব্রাউজার প্রয়োজনীয় শংসাপত্র সহ অনুরোধটি পুনরায় চেষ্টা করবে।
অনুরোধের শিরোনাম
Sec-Fetch-Storage-Access: <access-status>
যখন কোনও ব্যবহারকারী এমন কোনও পৃষ্ঠা পরিদর্শন করেন যেখানে ক্রস-সাইট কন্টেন্ট এম্বেড করা থাকে, তখন ব্রাউজার স্বয়ংক্রিয়ভাবে ক্রস-সাইট অনুরোধগুলিতে Sec-Fetch-Storage-Access হেডার অন্তর্ভুক্ত করবে যার জন্য শংসাপত্রের প্রয়োজন হতে পারে (যেমন কুকিজ)। এই হেডারটি এম্বেডের কুকি অ্যাক্সেস অনুমতির স্থিতি নির্দেশ করে। এর মানগুলি কীভাবে ব্যাখ্যা করবেন তা এখানে দেওয়া হল:
-
none: এম্বেডেরstorage-accessঅনুমতি নেই, এবং তাই পার্টিশনবিহীন কুকিতে অ্যাক্সেস নেই। -
inactive: এম্বেডেরstorage-accessঅনুমতি আছে, কিন্তু এটি ব্যবহার করার জন্য বেছে নেওয়া হয়নি। এম্বেডের পার্টিশনবিহীন কুকি অ্যাক্সেস নেই। -
active: এম্বেডটিতে পার্টিশনবিহীন কুকি অ্যাক্সেস রয়েছে। এই মানটি পার্টিশনবিহীন কুকিতে অ্যাক্সেস থাকা যেকোনো ক্রস-অরিজিন অনুরোধে অন্তর্ভুক্ত করা হবে।
প্রতিক্রিয়া শিরোনাম
Activate-Storage-Access: <retry-or-reload>
Activate-Storage-Access হেডার ব্রাউজারকে কুকিজ দিয়ে অনুরোধটি পুনরায় চেষ্টা করার নির্দেশ দেয় অথবা SAA সক্রিয় করে সরাসরি রিসোর্স লোড করার নির্দেশ দেয়। হেডারের নিম্নলিখিত মান থাকতে পারে:
-
load: ব্রাউজারকে অনুরোধকৃত রিসোর্সের জন্য পার্টিশনবিহীন কুকিতে এম্বেডার অ্যাক্সেস দেওয়ার নির্দেশ দেয়। -
retry: সার্ভার সাড়া দেয় যে ব্রাউজারটি স্টোরেজ-অ্যাক্সেস অনুমতি সক্রিয় করবে, তারপর অনুরোধটি পুনরায় চেষ্টা করুন।
Activate-Storage-Access: retry; allowed-origin="https://site.example"
Activate-Storage-Access: retry; allowed-origin=*
Activate-Storage-Access: load
নন-আইফ্রেম রিসোর্সের জন্য সমর্থন
স্টোরেজ অ্যাক্সেস হেডার আপডেট আইফ্রেমবিহীন এম্বেডেড কন্টেন্টের জন্য SAA সক্ষম করে, যেমন ভিন্ন ডোমেনে হোস্ট করা ছবি। পূর্বে, কোনও ওয়েব প্ল্যাটফর্ম API তৃতীয় পক্ষের কুকিজ অনুপলব্ধ থাকলে ব্রাউজারে শংসাপত্র সহ এই জাতীয় সংস্থানগুলি লোড করার অনুমতি দেয় না। উদাহরণস্বরূপ, আপনার embedding-site.example একটি চিত্রের অনুরোধ করতে পারে:
<img src="https://server.example/image"/>
এবং সার্ভারটি কুকি উপলব্ধ কিনা তার উপর নির্ভর করে কন্টেন্ট বা ত্রুটি সহ প্রতিক্রিয়া জানাতে পারে:
app.get('/image', (req, res) => {
const headers = req.headers;
const cookieHeader = headers.cookie;
// Check if the embed has the necessary cookie access
if (!cookieHeader || !cookieHeader.includes('foo')) {
// If the cookie is not present, check if the browser supports Storage Access headers
if (
'sec-fetch-storage-access' in headers &&
headers['sec-fetch-storage-access'] == 'inactive'
) {
// If the browser supports Storage Access API, retry the request with storage access enabled
res.setHeader('Activate-Storage-Access', 'retry; allowed-origin="https://embedding-site.example"');
}
res.status(401).send('No cookie!');
} else {
// If the cookie is available, check if the user is authorized to access the image
if (!check_authorization(cookieHeader)) {
return res.status(401).send('Unauthorized!');
}
// If the user is authorized, respond with the image file
res.sendFile("path/to/image.jpeg");
}
});
যদি কুকিটি উপলব্ধ না থাকে, তাহলে সার্ভার Sec-Fetch-Storage-Access অনুরোধ হেডারের মান পরীক্ষা করে। যদি এই মানটি inactive তে সেট করা থাকে, তাহলে সার্ভার Activate-Storage-Access: retry হেডার দিয়ে সাড়া দেয়, যা নির্দেশ করে যে অনুরোধটি স্টোরেজ অ্যাক্সেস দিয়ে পুনরায় চেষ্টা করা উচিত। যদি কোনও কুকি না থাকে এবং Sec-Fetch-Storage-Access হেডারে মানটি নিষ্ক্রিয় না থাকে, তাহলে ছবিটি লোড হবে না।
HTTP হেডার ফ্লো
HTTP হেডারের সাহায্যে, ব্রাউজারটি সনাক্ত করতে পারে যে ব্যবহারকারী কখন উইজেটকে স্টোরেজ-অ্যাক্সেসের অনুমতি দিয়েছে এবং পরবর্তী ভিজিটের সময় পার্টিশনবিহীন কুকিতে অ্যাক্সেস সহ আইফ্রেম লোড করতে পারে।
স্টোরেজ অ্যাক্সেস হেডারের সাহায্যে, পরবর্তী পৃষ্ঠাগুলি পরিদর্শন করলে নিম্নলিখিত প্রবাহটি ট্রিগার হবে:
- ব্যবহারকারী আবার
website.exampleভিজিট করেন যেখানেcalendar.exampleআবার এমবেড করা আছে। এই ফেচটি এখনও আগের মতো কুকিতে অ্যাক্সেস পায়নি। তবে, ব্যবহারকারী পূর্বেstorage-accessঅনুমতি দিয়েছেন এবং ফেচটিতে একটিSec-Fetch-Storage-Access: inactiveহেডার রয়েছে, যা নির্দেশ করে যে পার্টিশনবিহীন কুকি অ্যাক্সেস উপলব্ধ কিন্তু ব্যবহারে নেই। -
calendar.exampleসার্ভারটি একটিActivate-Storage-Access: retry; allowed-origin="<origin>"হেডার দিয়ে সাড়া দেয় (এই ক্ষেত্রে,<origin>হবেhttps://website.example), যা নির্দেশ করে যে রিসোর্স ফেচের জন্য স্টোরেজ-অ্যাক্সেস অনুমতি সহ পার্টিশনবিহীন কুকি ব্যবহার করা প্রয়োজন। - ব্রাউজারটি অনুরোধটি পুনরায় চেষ্টা করে, এবার পার্টিশনবিহীন কুকিজ সহ (এই আনচেকের জন্য
storage-accessঅনুমতি সক্রিয় করা হচ্ছে)। -
calendar.exampleসার্ভারটি ব্যক্তিগতকৃত iframe কন্টেন্টের সাথে সাড়া দেয়। এই রেসপন্সে একটিActivate-Storage-Access: loadহেডার থাকে, যা নির্দেশ করে যে ব্রাউজারটিstorage-accessঅনুমতি সক্রিয় করে কন্টেন্ট লোড করবে (অন্য কথায়, পার্টিশনবিহীন কুকি অ্যাক্সেস সহ লোড করুন, যেনdocument.requestStorageAccess()কল করা হয়েছে)। - ব্যবহারকারী এজেন্ট স্টোরেজ-অ্যাক্সেস অনুমতি ব্যবহার করে পার্টিশনবিহীন কুকি অ্যাক্সেস সহ আইফ্রেম কন্টেন্ট লোড করে। এই ধাপের পরে, উইজেটটি প্রত্যাশা অনুযায়ী কাজ করতে পারে।

আপনার সমাধান আপডেট করুন
স্টোরেজ অ্যাক্সেস হেডার বৈশিষ্ট্যের সাহায্যে, আপনি দুটি ক্ষেত্রে আপনার কোড আপডেট করতে চাইতে পারেন:
- আপনি SAA ব্যবহার করেন এবং হেডার লজিকের মাধ্যমে আরও ভালো পারফরম্যান্স অর্জন করতে চান।
- আপনার সার্ভারে অনুরোধে
Originহেডার অন্তর্ভুক্ত কিনা তার উপর নির্ভর করে আপনার একটি বৈধতা বা যুক্তি রয়েছে।
SAA হেডার লজিক বাস্তবায়ন করুন
আপনার সমাধানে স্টোরেজ অ্যাক্সেস হেডার ব্যবহার করার জন্য, আপনাকে আপনার সমাধান আপডেট করতে হবে। ধরুন আপনি calendar.example এর মালিক। website.example একটি ব্যক্তিগতকৃত calendar.example উইজেট লোড করতে সক্ষম হওয়ার জন্য, উইজেট কোডটিতে স্টোরেজ অ্যাক্সেস থাকতে হবে।
ক্লায়েন্ট পক্ষ
স্টোরেজ অ্যাক্সেস হেডার বৈশিষ্ট্যটির জন্য বিদ্যমান সমাধানগুলির জন্য ক্লায়েন্ট সাইডে কোনও কোড আপডেটের প্রয়োজন হয় না। SAA কীভাবে বাস্তবায়ন করবেন তা জানতে ডকুমেন্টেশনটি পড়ুন।
সার্ভার সাইড
সার্ভার সাইডে, আপনি নতুন হেডারগুলি ব্যবহার করতে পারেন:
app.get('/cookie-access-endpoint', (req, res) => {
const storageAccessHeader = req.headers['sec-fetch-storage-access'];
if (storageAccessHeader === 'inactive') {
// User needs to grant permission, trigger a prompt
if (!validate_origin(req.headers.origin)) {
res.status(401).send(`${req.headers.origin} is not allowed to send` +
' credentialed requests to this server.');
return;
}
res.set('Activate-Storage-Access', `retry; allowed-origin="${req.headers.origin}"`);
res.status(401).send('This resource requires storage access. Please grant permission.');
} else if (storageAccessHeader === 'active') {
// User has granted permission, proceed with access
res.set('Activate-Storage-Access', 'load');
// Include the actual iframe content here
res.send('This is the content that requires cookie access.');
} else {
// Handle other cases (e.g., 'Sec-Fetch-Storage-Access': 'none')
}
});
এই সমাধানটি বাস্তবে কীভাবে কাজ করে তা দেখতে ডেমোটি দেখুন।
আপনার অরিজিন হেডার লজিক আপডেট করুন
স্টোরেজ অ্যাক্সেস হেডারের সাহায্যে, Chrome আগের তুলনায় আরও বেশি অনুরোধে Origin হেডার পাঠায়। এটি আপনার সার্ভার-সাইড লজিককে প্রভাবিত করতে পারে যদি এটি শুধুমাত্র নির্দিষ্ট ধরণের অনুরোধের জন্য (যেমন CORS দ্বারা সংজ্ঞায়িত) উপস্থিত থাকার উপর নির্ভর করে।
সম্ভাব্য সমস্যা এড়াতে, আপনাকে আপনার সার্ভার-সাইড কোড পর্যালোচনা করতে হবে:
-
Originহেডারের উপস্থিতির উপর নির্ভর করে এমন কোনও বৈধতা বা যুক্তি পরীক্ষা করুন। - আরও ক্ষেত্রে
Originহেডার উপস্থিত থাকার জন্য আপনার কোড আপডেট করুন।
মূল সুবিধা
SAA ব্যবহারের জন্য স্টোরেজ অ্যাক্সেস হেডার একটি প্রস্তাবিত এবং আরও কার্যকর উপায়। সামগ্রিকভাবে, এই পরিবর্তনটি বেশ কয়েকটি উন্নতি নিয়ে আসে:
- নন-আইফ্রেম এম্বেড সাপোর্ট: বিস্তৃত পরিসরের রিসোর্সের জন্য SAA সক্ষম করে।
- কম নেটওয়ার্ক ব্যবহার: কম অনুরোধ এবং কম পেলোড।
- কম CPU ব্যবহার: কম জাভাস্ক্রিপ্ট প্রক্রিয়াকরণ।
- উন্নত UX: বিঘ্নকারী মধ্যবর্তী লোড দূর করে।
অরিজিন ট্রায়ালে অংশগ্রহণ করুন
অরিজিন ট্রায়াল আপনাকে নতুন বৈশিষ্ট্যগুলি চেষ্টা করার এবং তাদের ব্যবহারযোগ্যতা, ব্যবহারিকতা এবং কার্যকারিতা সম্পর্কে প্রতিক্রিয়া জানাতে দেয়। আরও তথ্যের জন্য, "অরিজিন ট্রায়াল দিয়ে শুরু করুন" দেখুন।
আপনি Chrome 130 থেকে শুরু করে অরিজিন ট্রায়ালের জন্য নিবন্ধন করে স্টোরেজ অ্যাক্সেস হেডার বৈশিষ্ট্যটি ব্যবহার করে দেখতে পারেন। অরিজিন ট্রায়ালে অংশগ্রহণ করতে:
- স্টোরেজ অ্যাক্সেস হেডারের অরিজিন ট্রায়াল রেজিস্ট্রেশন পৃষ্ঠায় যান।
- অরিজিন ট্রায়ালে অংশগ্রহণের নির্দেশাবলী অনুসরণ করুন।
স্থানীয়ভাবে পরীক্ষা করুন
আপনার ওয়েবসাইটটি এই পরিবর্তনের জন্য প্রস্তুত কিনা তা নিশ্চিত করতে আপনি স্থানীয়ভাবে স্টোরেজ অ্যাক্সেস হেডার বৈশিষ্ট্যটি পরীক্ষা করতে পারেন।
আপনার Chrome ইন্সট্যান্স কনফিগার করতে এই ধাপগুলি অনুসরণ করুন:
-
chrome://flags/#storage-access-headersএ chrome ফ্ল্যাগ সক্ষম করুন। - পরিবর্তনগুলি কার্যকর হওয়ার জন্য Chrome পুনরায় চালু করুন।
অংশগ্রহণ করুন এবং মতামত শেয়ার করুন
আপনার যদি কোনও প্রতিক্রিয়া থাকে বা কোনও সমস্যার সম্মুখীন হন, তাহলে আপনি একটি সমস্যা দায়ের করতে পারেন। আপনি GitHub ব্যাখ্যাকারীতে স্টোরেজ অ্যাক্সেস হেডার সম্পর্কে আরও জানতে পারেন।