Reporting API-এর মাধ্যমে আপনার ওয়েব অ্যাপ্লিকেশন মনিটর করা

নিরাপত্তা লঙ্ঘন, বাতিল করা API কল এবং আরও অনেক কিছু মনিটর করতে রিপোর্টিং API ব্যবহার করুন।

কিছু সমস্যা শুধু প্রোডাকশনেই হয়। আপনি এগুলি লোকালি বা ডেভেলপমেন্টের সময় দেখতে পাবেন না কারণ আসল ব্যবহারকারী, আসল নেটওয়ার্ক ও আসল ডিভাইস গেমের অভিজ্ঞতা পরিবর্তন করে দেয়। Reporting API এইসব সমস্যার কিছু সমাধান করতে সাহায্য করে—যেমন আপনার সাইট জুড়ে নিরাপত্তা লঙ্ঘন বা বাতিল করা এবং শীঘ্রই বাতিল করা হবে এমন API কল এবং আপনি নির্দিষ্ট করেছেন এমন এন্ডপয়েন্টে সেগুলি ট্রান্সমিট করে।

HTTP হেডার ব্যবহার করে আপনি কী মনিটর করতে চান তা ঘোষণা করতে দেয় এবং এটি ব্রাউজার দ্বারা পরিচালিত হয়।

Reporting API সেট-আপ করলে আপনি নিশ্চিন্ত থাকতে পারবেন যে ব্যবহারকারীরা এই ধরনের সমস্যার সম্মুখীন হলে আপনি তা জানতে পারবেন এবং সমাধান করতে পারবেন।

এই API কী করতে পারে এবং কীভাবে এটি ব্যবহার করতে হয় তা এই পোস্টে কভার করা হয়েছে। আসুন, আরও গভীরে যাওয়া যাক!

এক নজরে

রিপোর্ট তৈরি থেকে শুরু করে ডেভেলপার কর্তৃক রিপোর্ট অ্যাক্সেস করা পর্যন্ত নিচে উল্লেখ করা ধাপগুলির সারসংক্ষেপ করে এমন ডায়াগ্রাম
কীভাবে রিপোর্ট তৈরি ও পাঠানো হয়।

ধরা যাক, আপনার সাইট, site.example-এ Content-Security-Policy এবং Document-Policy আছে। এগুলি কী করে তা জানেন না? কোনও অসুবিধা নেই, আপনি এখনও এই উদাহরণটি বুঝতে পারবেন।

আপনি নিজের সাইট মনিটর করার সিদ্ধান্ত নিয়েছেন যাতে এইসব নীতি কখন লঙ্ঘন করা হচ্ছে তা জানতে পারেন, তবে আপনি সেইসব API-এর উপরও নজর রাখতে চান যেগুলি বন্ধ হয়ে গেছে বা শীঘ্রই বন্ধ হয়ে যাবে এবং আপনার কোডবেস সেগুলি ব্যবহার করতে পারে।

এটি করতে, আপনি একটি Reporting-Endpoints হেডার কনফিগার করেন এবং যেখানে প্রয়োজন সেখানে আপনার নীতিতে report-to নির্দেশিকা ব্যবহার করে এই এন্ডপয়েন্টের নাম ম্যাপ করেন।

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the `default` endpoint

অপ্রত্যাশিত কিছু ঘটে এবং আপনার কিছু ব্যবহারকারীর জন্য এইসব নীতি লঙ্ঘন করা হয়।

লঙ্ঘনের উদাহরণ

index.html

<script src="script.js"></script>
<!-- CSP VIOLATION: Try to load a script that's forbidden as per the Content-Security-Policy -->
<script src="https://example.com/script.js"></script>

script.js, index.html লোড করেছেন

// DOCUMENT-POLICY VIOLATION: Attempt to use document.write despite the document policy
try {
  document.write('<h1>hi</h1>');
} catch (e) {
  console.log(e);
}
// DEPRECATION: Call a deprecated API
const webkitStorageInfo = window.webkitStorageInfo;

ব্রাউজার একটি CSP লঙ্ঘন সংক্রান্ত রিপোর্ট, একটি ডকুমেন্ট-পলিসি লঙ্ঘন রিপোর্ট এবং একটি ডেপ্রিকেশন রিপোর্ট তৈরি করে যা এই সমস্যাগুলি ক্যাপচার করে।

এক মিনিট পর্যন্ত সামান্য দেরি করে—ব্রাউজার তারপরে এই লঙ্ঘনের ধরনের জন্য কনফিগার করা এন্ডপয়েন্টে রিপোর্ট পাঠায়। রিপোর্টগুলি ব্রাউজার নিজেই আউট-অফ-ব্যান্ড পাঠায় (আপনার সার্ভার বা আপনার সাইট দ্বারা নয়)।

এন্ডপয়েন্ট এইসব রিপোর্ট পায়।

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

উদাহরণ রিপোর্ট

{
  "age": 2,
  "body": {
    "blockedURL": "https://site2.example/script.js",
    "disposition": "enforce",
    "documentURL": "https://site.example",
    "effectiveDirective": "script-src-elem",
    "originalPolicy": "script-src 'self'; object-src 'none'; report-to main-endpoint;",
    "referrer": "https://site.example",
    "sample": "",
    "statusCode": 200
  },
  "type": "csp-violation",
  "url": "https://site.example",
  "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
}

ব্যবহারের ক্ষেত্র ও রিপোর্টের ধরন

আপনার সাইট জুড়ে ঘটে চলা বিভিন্ন ধরনের গুরুত্বপূর্ণ সতর্কতা বা সমস্যা মনিটর করার ব্যাপারে সাহায্য করতে, Reporting API কনফিগার করা যেতে পারে:

রিপোর্টের ধরন এমন একটি পরিস্থিতির উদাহরণ যেখানে রিপোর্ট তৈরি করা হবে
CSP লঙ্ঘন (শুধুমাত্র লেভেল ৩) আপনি নিজের কোনও একটি পৃষ্ঠায় Content-Security-Policy (CSP) সেট করেছেন, কিন্তু পৃষ্ঠাটি এমন একটি স্ক্রিপ্ট লোড করার চেষ্টা করছে যা আপনার CSP দ্বারা অনুমোদিত নয়।
COOP লঙ্ঘন আপনি একটি পৃষ্ঠায় Cross-Origin-Opener-Policy সেট করেছেন, কিন্তু একটি ক্রস-অরিজিন উইন্ডো সরাসরি ডকুমেন্টের সাথে ইন্টার‍্যাক্ট করার চেষ্টা করছে।
COEP লঙ্ঘন আপনি কোনও পৃষ্ঠায় Cross-Origin-Embedder-Policy সেট করেছেন, কিন্তু ডকুমেন্টে ক্রস-অরিজিন আইফ্রেম অন্তর্ভুক্ত আছে যা ক্রস-অরিজিন ডকুমেন্ট দ্বারা লোড হওয়ার জন্য অপ্ট-ইন করেনি।
ডকুমেন্ট সংক্রান্ত নীতি লঙ্ঘন পৃষ্ঠায় একটি ডকুমেন্ট নীতি আছে যা document.write-এর ব্যবহার আটকায়, কিন্তু একটি স্ক্রিপ্ট document.write-কে কল করার চেষ্টা করে।
অনুমতি সংক্রান্ত নীতি লঙ্ঘন পৃষ্ঠাটিতে একটি অনুমতি নীতি রয়েছে যা মাইক্রোফোন ব্যবহার করতে বাধা দেয় এবং একটি স্ক্রিপ্ট যা অডিও ইনপুটের জন্য অনুরোধ করে।
বন্ধ করা সংক্রান্ত সতর্কতা পৃষ্ঠাটি এমন একটি API ব্যবহার করছে যা বন্ধ করা হয়েছে বা বন্ধ করা হবে; এটি সরাসরি বা টপ-লেভেল থার্ড-পার্টি স্ক্রিপ্ট ব্যবহার করে এটিকে কল করে।
হস্তক্ষেপ পৃষ্ঠাটি এমন কিছু করার চেষ্টা করছে যা ব্রাউজার নিরাপত্তা, পারফর্ম্যান্স বা ব্যবহারকারীর অভিজ্ঞতার কারণে না করার সিদ্ধান্ত নিয়েছে। Chrome-এ উদাহরণ: পৃষ্ঠাটি স্লো নেটওয়ার্কে document.write ব্যবহার করে অথবা ক্রস-অরিজিন ফ্রেমে navigator.vibrate কল করে যার সাথে ব্যবহারকারী এখনও ইন্টার‍্যাক্ট করেননি।
ক্র্যাশ আপনার সাইট খোলা থাকাকালীন ব্রাউজার ক্র্যাশ করে।

রিপোর্ট

আপনার কনফিগার করা এন্ডপয়েন্টে ব্রাউজার রিপোর্ট পাঠায়। এটি নিম্নলিখিত অনুরোধ পাঠায়:

POST
Content-Type: application/reports+json

এইসব অনুরোধের পেলোড হল রিপোর্টের একটি তালিকা।

রিপোর্টের তালিকার উদাহরণ

[
  {
    "age": 420,
    "body": {
      "columnNumber": 12,
      "disposition": "enforce",
      "lineNumber": 11,
      "message": "Document policy violation: document-write is not allowed in this document.",
      "policyId": "document-write",
      "sourceFile": "https://site.example/script.js"
    },
    "type": "document-policy-violation",
    "url": "https://site.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  },
  {
    "age": 510,
    "body": {
      "blockedURL": "https://site.example/img.jpg",
      "destination": "image",
      "disposition": "enforce",
      "type": "corp"
    },
    "type": "coep",
    "url": "https://dummy.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  }
]

এইসব রিপোর্টের প্রত্যেকটিতে আপনি এই ডেটা দেখতে পাবেন:

ফিল্ড বিবরণ
age রিপোর্টের টাইমস্ট্যাম্প ও বর্তমান সময়ের মধ্যে মিলিসেকেন্ডের সংখ্যা।
body JSON স্ট্রিংয়ে সিরিয়ালাইজ করা আসল রিপোর্টের ডেটা। রিপোর্টের type-এর মাধ্যমে রিপোর্টের body-এ থাকা ফিল্ড নির্ধারণ করা হয়। ⚠️ বিভিন্ন ধরনের রিপোর্টের আলাদা আলাদা বডি থাকে।
type রিপোর্টের ধরন, যেমন csp-violation বা coep।
url যে ডকুমেন্ট বা কর্মী থেকে রিপোর্ট তৈরি করা হয়েছে তার ঠিকানা। ইউজারনেম, পাসওয়ার্ড ও ফ্র্যাগমেন্টের মতো সংবেদনশীল ডেটা এই URL থেকে সরিয়ে দেওয়া হয়েছে।
user_agent রিপোর্টটি যে অনুরোধ থেকে তৈরি করা হয়েছে তার User-Agent হেডার।

ক্রেডেনশিয়ালযুক্ত রিপোর্ট

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

ক্রেডেনশিয়াল থেকে রিপোর্ট সম্পর্কে অতিরিক্ত তথ্য পাওয়া যেতে পারে; যেমন, কোনও ব্যবহারকারীর অ্যাকাউন্ট থেকে ক্রমাগত সমস্যা হচ্ছে কিনা অথবা অন্য পৃষ্ঠায় কোনও নির্দিষ্ট অ্যাকশন নেওয়ার ফলে এই পৃষ্ঠায় রিপোর্ট ট্রিগার হচ্ছে কিনা।

ব্রাউজার কখন ও কীভাবে রিপোর্ট পাঠায়?

আপনার সাইট থেকে আউট-অফ-ব্যান্ড রিপোর্ট পাঠানো হয়: কনফিগার করা এন্ডপয়েন্টে কখন রিপোর্ট পাঠানো হবে তা ব্রাউজার নিয়ন্ত্রণ করে। এছাড়াও, ব্রাউজার কখন রিপোর্ট পাঠাবে তা নিয়ন্ত্রণ করার কোনও উপায় নেই; এটি উপযুক্ত সময়ে অটোমেটিক রিপোর্ট ক্যাপচার, সারিবদ্ধ ও পাঠায়।

এর অর্থ হল, Reporting API ব্যবহার করার সময় পারফর্ম্যান্স নিয়ে কোনও চিন্তা করতে হয় না।

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

থার্ড-পার্টি ও ফার্স্ট-পার্টি সংক্রান্ত সমস্যা

আপনার পৃষ্ঠায় হওয়া লঙ্ঘন বা অবমূল্যায়নের কারণে তৈরি হওয়া রিপোর্ট আপনার কনফিগার করা এন্ডপয়েন্টে পাঠানো হবে। আপনার পৃষ্ঠায় চলা থার্ড-পার্টি স্ক্রিপ্ট দ্বারা করা লঙ্ঘনও এর মধ্যে অন্তর্ভুক্ত।

আপনার পৃষ্ঠায় এম্বেড করা ক্রস-অরিজিন iframe-এ হওয়া লঙ্ঘন বা অবমূল্যায়ন আপনার এন্ডপয়েন্টে রিপোর্ট করা হবে না (অন্তত ডিফল্ট হিসেবে নয়)। iframe নিজস্ব রিপোর্টিং সেট-আপ করতে পারে এবং এমনকি আপনার সাইটের—অর্থাৎ, ফার্স্ট-পার্টির—রিপোর্টিং পরিষেবাতে রিপোর্ট করতে পারে; তবে এটি ফ্রেম করা সাইটের উপর নির্ভর করে। এছাড়াও মনে রাখবেন যে কোনও পৃষ্ঠার নীতি লঙ্ঘিত হলে তবেই বেশিরভাগ রিপোর্ট তৈরি করা হয় এবং আপনার পৃষ্ঠার নীতি এবং iframe-এর নীতি আলাদা।

বন্ধ হয়ে যাওয়া ফিচার সহ উদাহরণ

আপনার পৃষ্ঠায় Reporting-Endpoints হেডার সেট-আপ করা থাকলে: আপনার পৃষ্ঠায় চলা থার্ড-পার্টি স্ক্রিপ্টের মাধ্যমে কল করা বন্ধ হয়ে যাওয়া API আপনার এন্ডপয়েন্টে রিপোর্ট করা হবে। আপনার পৃষ্ঠায় এম্বেড করা iframe-এর মাধ্যমে কল করা বন্ধ হয়ে যাওয়া API আপনার এন্ডপয়েন্টে রিপোর্ট করা হবে না। iframe সার্ভার রিপোর্টিং-এন্ডপয়েন্ট সেট-আপ করলে তবেই ডেপ্রিকেশন রিপোর্ট তৈরি করা হবে এবং iframe-এর সার্ভার যে এন্ডপয়েন্ট সেট-আপ করেছে সেখানে এই রিপোর্ট পাঠানো হবে।
আপনার পৃষ্ঠায় Reporting-Endpoints হেডার সেট-আপ করা থাকলে: আপনার পৃষ্ঠায় চলা থার্ড-পার্টি স্ক্রিপ্টের মাধ্যমে কল করা বন্ধ হয়ে যাওয়া API আপনার এন্ডপয়েন্টে রিপোর্ট করা হবে। আপনার পৃষ্ঠায় এম্বেড করা iframe-এর মাধ্যমে কল করা বন্ধ হয়ে যাওয়া API আপনার এন্ডপয়েন্টে রিপোর্ট করা হবে না। iframe সার্ভার রিপোর্টিং-এন্ডপয়েন্ট সেট-আপ করলে তবেই শুধু অবলোপন রিপোর্ট তৈরি করা হবে এবং iframe সার্ভার যে এন্ডপয়েন্ট সেট-আপ করেছে সেখানে এই রিপোর্ট পাঠানো হবে।

ব্রাউজার সহায়তা

নিচে দেওয়া সারণী Reporting API v1-এর জন্য ব্রাউজার সাপোর্টকে সংক্ষিপ্তভাবে তুলে ধরে, যা Reporting-Endpoints হেডার সহ। Reporting API-এর জন্য ব্রাউজার সাপোর্ট v0 (Report-To হেডার) একই, শুধু একটি রিপোর্টের ধরন ছাড়া: নেটওয়ার্কের সমস্যা নতুন Reporting API-তে লগিং কাজ করে না। বিস্তারিত জানতে মাইগ্রেশন গাইড পড়ুন।

রিপোর্টের ধরন Chrome Chrome iOS Safari Firefox Edge
CSP লঙ্ঘন (শুধুমাত্র লেভেল ৩)* হ্যাঁ হ্যাঁ হ্যাঁ ✘ না হ্যাঁ
নেটওয়ার্কের সমস্যার লগিং ✘ না ✘ না ✘ না ✘ না ✘ না
COOP/COEP লঙ্ঘন ✔ হ্যাঁ ✘ না ✔ হ্যাঁ ✘ না ✔ হ্যাঁ
অন্যান্য সব ধরনের: ডকুমেন্ট নীতি লঙ্ঘন, অবচিতি, হস্তক্ষেপ, ক্র্যাশ হ্যাঁ ✘ না ✘ না ✘ না ✔ হ্যাঁ

এই সারণীটি শুধুমাত্র নতুন Reporting-Endpoints হেডারের সাথে report-to-এর জন্য সহায়তা সংক্ষিপ্ত করে। আপনি Reporting-Endpoints-এ মাইগ্রেট করতে চাইলে CSP রিপোর্টিং মাইগ্রেশন পরামর্শ পড়ুন।

Reporting API ব্যবহার করা

কোথায় রিপোর্ট পাঠানো হবে তা ঠিক করা

আপনার কাছে দুটি বিকল্প আছে:

  • আগে থেকে থাকা রিপোর্ট সংগ্রহকারী পরিষেবায় রিপোর্ট পাঠানো।
  • আপনার তৈরি ও অপারেট করা রিপোর্টিং কালেক্টরে রিপোর্ট পাঠান।

বিকল্প ১: আগে থেকে থাকা রিপোর্ট সংগ্রহকারী পরিষেবা ব্যবহার করা

রিপোর্ট কালেক্টর পরিষেবার কিছু উদাহরণ হল:

আপনি যদি অন্য কোনও সমাধান জানেন, তাহলে আমাদের জানাতে একটি সমস্যা খুলুন এবং আমরা এই পোস্টটি আপডেট করব!

দাম ছাড়াও, রিপোর্ট কালেক্টর বেছে নেওয়ার সময় নিম্নলিখিত বিষয়গুলি বিবেচনা করুন: 🧐

  • এই কালেক্টর কি সব ধরনের রিপোর্ট সাপোর্ট করে? যেমন, সব রিপোর্টিং এন্ডপয়েন্ট সলিউশন COOP/COEP রিপোর্ট সাপোর্ট করে না।
  • আপনি কি কোনও থার্ড-পার্টি রিপোর্ট সংগ্রহকারীর সাথে আপনার অ্যাপ্লিকেশনের URL শেয়ার করতে স্বচ্ছন্দ বোধ করেন? এমনকি ব্রাউজার এইসব URL থেকে সংবেদনশীল তথ্য সরিয়ে দিলেও, সংবেদনশীল তথ্য এইভাবে ফাঁস হয়ে যেতে পারে। আপনার অ্যাপ্লিকেশনের জন্য এটি খুব ঝুঁকিপূর্ণ মনে হলে, আপনার নিজস্ব রিপোর্টিং এন্ডপয়েন্ট অপারেট করুন।

বিকল্প ২: আপনার নিজস্ব রিপোর্ট সংগ্রহকারী তৈরি ও পরিচালনা করা

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

আপনি নিজের রিপোর্ট সংগ্রহকারী তৈরি করলে:

  • আপনার এন্ডপয়েন্টে ব্রাউজারের পাঠানো রিপোর্ট সংক্রান্ত অনুরোধ শনাক্ত করতে application/reports+json-এর Content-Type সহ POST অনুরোধ চেক করুন।
  • আপনার সাইটের থেকে আলাদা অরিজিনে এন্ডপয়েন্ট থাকলে, এটি CORS প্রিফ্লাইট অনুরোধ সাপোর্ট করে কিনা তা নিশ্চিত করুন।

বিকল্প ৩: বিকল্প ১ ও ২ একত্রিত করুন

আপনি হয়ত কোনও নির্দিষ্ট পরিষেবা প্রদানকারীকে কিছু ধরনের রিপোর্ট ম্যানেজ করতে দিতে চান, কিন্তু অন্যান্য রিপোর্টের জন্য ইন-হাউস সমাধান চান।

এই ক্ষেত্রে, নিম্নলিখিতভাবে একাধিক এন্ডপয়েন্ট সেট করুন:

Reporting-Endpoints: endpoint-1="https://reports-collector.example", endpoint-2="https://my-custom-endpoint.example"

Reporting-Endpoints হেডার কনফিগার করুন

Reporting-Endpoints রেসপন্স হেডার সেট করুন। এর মান অবশ্যই একটি বা কমা-সেপারেটেড কী-ভ্যালু পেয়ারের সিরিজ হতে হবে:

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

আপনি যদি পুরনো রিপোর্টিং API থেকে নতুন রিপোর্টিং API-তে মাইগ্রেট করেন, তাহলে Reporting-Endpoints এবং Report-To দুটিই সেট করা যুক্তিযুক্ত হতে পারে। মাইগ্রেশন গাইড থেকে বিবরণ দেখুন। বিশেষ করে, আপনি যদি শুধুমাত্র report-uri নির্দেশিকা ব্যবহার করে Content-Security-Policy লঙ্ঘনের জন্য রিপোর্টিং ব্যবহার করেন, তাহলে CSP রিপোর্টিংয়ের জন্য মাইগ্রেশন ধাপ চেক করুন।

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Report-To: ...

কী (এন্ডপয়েন্টের নাম)

প্রতিটি কী আপনার পছন্দমতো নাম হতে পারে, যেমন main-endpoint বা endpoint-1। আপনি বিভিন্ন ধরনের রিপোর্টের জন্য আলাদা আলাদা নামের এন্ডপয়েন্ট সেট করার সিদ্ধান্ত নিতে পারেন—যেমন, my-coop-endpoint, my-csp-endpoint। এর সাহায্যে, আপনি রিপোর্টের ধরন অনুযায়ী সেগুলিকে আলাদা আলাদা এন্ডপয়েন্টে রুট করতে পারবেন।

আপনি হস্তক্ষেপ, অবলোপ, ক্র্যাশ রিপোর্ট বা এগুলির কম্বিনেশন পেতে চাইলে, default নামের একটি এন্ডপয়েন্ট সেট করুন।

Reporting-Endpoints হেডারে কোনও default এন্ডপয়েন্ট উল্লেখ করা না থাকলে, এই ধরনের রিপোর্ট পাঠানো হবে না (যদিও সেগুলি তৈরি করা হবে)।

ভ্যালু (URL)

প্রতিটি ভ্যালু হল আপনার পছন্দের URL, যেখানে রিপোর্ট পাঠানো হবে। ধাপ ১-এ আপনি কী সিদ্ধান্ত নিয়েছেন তার উপর নির্ভর করে এখানে সেট করার জন্য URL বেছে নিন।

এন্ডপয়েন্ট URL:

উদাহরণ

Reporting-Endpoints: my-coop-endpoint="https://reports.example/coop", my-csp-endpoint="https://reports.example/csp", default="https://reports.example/default"

তারপরে, আপনি উপযুক্ত নীতিতে প্রতিটি নামযুক্ত এন্ডপয়েন্ট ব্যবহার করতে পারেন অথবা সব নীতি জুড়ে একটি সিঙ্গেল এন্ডপয়েন্ট ব্যবহার করতে পারেন।

হেডার কোথায় সেট করতে হবে?

নতুন রিপোর্টিং API-তে—যেটি এই পোস্টে কভার করা হয়েছে— রিপোর্ট ডকুমেন্ট-এর স্কোপে থাকে। এর অর্থ হল, কোনও একটি নির্দিষ্ট অরিজিনের জন্য, site.example/page1 এবং site.example/page2-এর মতো বিভিন্ন ডকুমেন্ট, বিভিন্ন এন্ডপয়েন্টে রিপোর্ট পাঠাতে পারে।

আপনার সাইটের যেকোনও পৃষ্ঠায় নীতি লঙ্ঘন বা অবচিতি সংক্রান্ত রিপোর্ট পেতে, সব উত্তরে মিডলওয়্যার হিসেবে হেডার সেট করুন।

Express-এ একটি উদাহরণ এখানে দেওয়া হল:

const REPORTING_ENDPOINT_BASE = 'https://report.example';
const REPORTING_ENDPOINT_MAIN = `${REPORTING_ENDPOINT_BASE}/main`;
const REPORTING_ENDPOINT_DEFAULT = `${REPORTING_ENDPOINT_BASE}/default`;

app.use(function (request, response, next) {
  // Set up the Reporting API
  response.set(
    'Reporting-Endpoints',
    `main-endpoint="${REPORTING_ENDPOINT_MAIN}", default="${REPORTING_ENDPOINT_DEFAULT}"`,
  );
  next();
});

আপনার নীতি এডিট করুন

এখন Reporting-Endpoints হেডার কনফিগার করা হয়েছে, প্রতিটি নীতি হেডারে report-to নির্দেশ যোগ করুন যার জন্য আপনি লঙ্ঘন সংক্রান্ত রিপোর্ট পেতে চান। report-to-এর ভ্যালু আপনার কনফিগার করা নামযুক্ত এন্ডপয়েন্টগুলির মধ্যে একটি হতে হবে।

আপনি একাধিক নীতির জন্য একাধিক এন্ডপয়েন্ট ব্যবহার করতে পারেন অথবা বিভিন্ন নীতি জুড়ে বিভিন্ন এন্ডপয়েন্ট ব্যবহার করতে পারেন।

প্রতিটি নীতির জন্য, report-to-এর ভ্যালু আপনার কনফিগার করা নামযুক্ত এন্ডপয়েন্টগুলির মধ্যে একটি হতে হবে।

অবচিতি, হস্তক্ষেপ এবং ক্র্যাশ রিপোর্টের জন্য report-to-এর প্রয়োজন নেই। এইসব রিপোর্ট কোনও নীতির সাথে আবদ্ধ নয়। যতক্ষণ পর্যন্ত default এন্ডপয়েন্ট সেট-আপ করা থাকে এবং এই default এন্ডপয়েন্টে পাঠানো হয়, ততক্ষণ পর্যন্ত এগুলি জেনারেট করা হয়।

উদাহরণ

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0;report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the default endpoint

আপনার রিপোর্টিং সেট-আপে থাকা সমস্যা সমাধান করা

ইচ্ছাকৃতভাবে রিপোর্ট জেনারেট করা

Reporting API সেট-আপ করার সময়, রিপোর্ট ঠিকমতো তৈরি ও পাঠানো হচ্ছে কিনা তা চেক করার জন্য আপনাকে হয়ত ইচ্ছাকৃতভাবে নীতি লঙ্ঘন করতে হবে।

সময় বাঁচান

রিপোর্ট পাঠাতে দেরি হতে পারে—প্রায় এক মিনিট, যা ডিবাগ করার সময় অনেক সময়। 😴 তবে, Chrome-এ ডিবাগ করার সময়, আপনি --short-reporting-delay ফ্ল্যাগ ব্যবহার করে রিপোর্ট তৈরি হওয়ার সাথে সাথেই তা পেতে পারেন।

এই ফ্ল্যাগ চালু করতে আপনার টার্মিনালে এই কমান্ডটি রান করুন:

YOUR_PATH/TO/EXECUTABLE/Chrome --short-reporting-delay

DevTools ব্যবহার করা

Chrome-এ, পাঠানো হয়েছে বা পাঠানো হবে এমন রিপোর্ট দেখতে DevTools ব্যবহার করুন।

অক্টোবর ২০২১ পর্যন্ত, এই ফিচারটি পরীক্ষামূলক পর্যায়ে রয়েছে। এটি ব্যবহার করতে, এইসব ধাপ অনুসরণ করুন:

  1. Chrome-এর 96 ও তার পরের যেকোনও ভার্সন ব্যবহার করুন (আপনার ব্রাউজারে chrome://version লিখে চেক করুন)
  2. Chrome-এর অ্যাড্রেস বারে chrome://flags/#enable-experimental-web-platform-features টাইপ বা পেস্ট করুন।
  3. চালু করা আছে বিকল্পে ক্লিক করুন।
  4. আপনার ব্রাউজার রিস্টার্ট করুন।
  5. Chrome DevTools খুলুন।
  6. Chrome DevTools-এ, সেটিংস খুলুন। 'এক্সপেরিমেন্ট' বিকল্পের অধীনে, অ্যাপ্লিকেশন প্যানেলে Reporting API প্যানেল চালু করুন বিকল্পে ক্লিক করুন।
  7. DevTools আবার লোড করুন।
  8. আপনার পৃষ্ঠা আবার লোড করুন। DevTools খোলা আছে এমন পৃষ্ঠার মাধ্যমে তৈরি করা রিপোর্ট Chrome DevTools-এর অ্যাপ্লিকেশন প্যানেলে, Reporting API-এর অধীনে তালিকাভুক্ত করা হবে।
Chrome DevTools-এ রিপোর্টের তালিকা দেখানো হচ্ছে।
Chrome DevTools আপনার পৃষ্ঠায় তৈরি হওয়া রিপোর্ট এবং সেগুলির স্ট্যাটাস দেখায়।

রিপোর্টের স্ট্যাটাস

রিপোর্টটি সফলভাবে পাঠানো হয়েছে কিনা তা স্ট্যাটাস কলাম থেকে জানতে পারবেন।

স্ট্যাটাস বিবরণ
Success ব্রাউজার রিপোর্ট পাঠিয়েছে এবং এন্ডপয়েন্ট একটি সাকসেস কোড (200 বা অন্য সাকসেস রেসপন্স কোড 2xx) দিয়ে উত্তর দিয়েছে।
Pending ব্রাউজার রিপোর্ট পাঠানোর চেষ্টা করছে।
Queued রিপোর্ট তৈরি করা হয়েছে এবং ব্রাউজার এটি পাঠানোর চেষ্টা করছে না। এই দুটি ক্ষেত্রের মধ্যে একটিতে রিপোর্ট Queued হিসেবে দেখা যায়:
  • রিপোর্টটি নতুন এবং ব্রাউজারটি পাঠানোর চেষ্টা করার আগে আরও রিপোর্ট আসে কিনা তা দেখার জন্য অপেক্ষা করছে।
  • রিপোর্টটি নতুন নয়; ব্রাউজারটি আগেই এই রিপোর্ট পাঠানোর চেষ্টা করেছে এবং ব্যর্থ হয়েছে এবং আবার চেষ্টা করার আগে অপেক্ষা করছে।
MarkedForRemoval কিছুক্ষণ (Queued) আবার চেষ্টা করার পরে, ব্রাউজার রিপোর্ট পাঠানোর চেষ্টা বন্ধ করে দিয়েছে এবং শীঘ্রই এটি পাঠানোর জন্য রিপোর্টের তালিকা থেকে সরিয়ে দেবে।

রিপোর্ট সফলভাবে পাঠানো হোক বা না হোক, কিছুক্ষণ পরে তা সরিয়ে দেওয়া হয়।

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

আপনার এন্ডপয়েন্টে কি প্রত্যাশিত রিপোর্ট তৈরি বা পাঠানো হচ্ছে না? এই সমস্যার সমাধান করার জন্য এখানে কয়েকটি পরামর্শ দেওয়া হল।

রিপোর্ট জেনারেট করা হয়নি

DevTools-এ দেখানো রিপোর্ট সঠিকভাবে তৈরি করা হয়েছে। আপনি যে রিপোর্টটি দেখতে চাইছেন সেটি এই তালিকায় দেখা না গেলে:

  • আপনার নীতিতে report-to চেক করুন। এটি ভুলভাবে কনফিগার করা হলে, রিপোর্ট তৈরি করা হবে না। এটি ঠিক করতে আপনার নীতি এডিট করুন বিকল্পে যান। এই সমস্যার সমাধান করার আরেকটি উপায় হল Chrome-এ DevTools কনসোল চেক করা: আপনি যে লঙ্ঘন আশা করেছিলেন সেটির জন্য কনসোলে কোনও সমস্যা পপ-আপ করলে, এর অর্থ হল আপনার নীতি সম্ভবত সঠিকভাবে কনফিগার করা হয়েছে।
  • মনে রাখবেন, শুধুমাত্র সেইসব রিপোর্ট এই তালিকায় দেখানো হবে যেগুলি সেই ডকুমেন্টের জন্য তৈরি করা হয়েছে যেখানে DevTools খোলা আছে। একটি উদাহরণ: আপনার সাইট site1.example যদি এমন কোনও iframe এম্বেড করে site2.example যা নীতি লঙ্ঘন করে এবং তার ফলে কোনও রিপোর্ট তৈরি হয়, তাহলে এই রিপোর্ট DevTools-এ তখনই দেখা যাবে যদি আপনি iframe-টি নিজস্ব উইন্ডোতে খোলেন এবং সেই উইন্ডোর জন্য DevTools খোলেন।

রিপোর্ট তৈরি করা হয়েছে কিন্তু পাঠানো বা পাওয়া যায়নি

আপনি যদি DevTools-এ একটি রিপোর্ট দেখতে পান, কিন্তু আপনার এন্ডপয়েন্ট সেটি না পায়, তাহলে কী হবে?

  • শর্ট ডিলে ব্যবহার করতে ভুলবেন না। আপনি রিপোর্ট দেখতে পাচ্ছেন না, কারণ এটি এখনও পাঠানো হয়নি!
  • আপনার Reporting-Endpoints হেডার কনফিগারেশন চেক করুন। এতে কোনও সমস্যা থাকলে, সঠিকভাবে তৈরি করা রিপোর্ট পাঠানো হবে না। এই ক্ষেত্রে, DevTools-এ রিপোর্টের স্ট্যাটাস Queued থাকবে (এটি Pending-এ পরিবর্তিত হতে পারে এবং ডেলিভারির চেষ্টা করা হলে দ্রুত Queued-এ ফিরে আসতে পারে)। কিছু সাধারণ ভুল যার কারণে এটি হতে পারে:

  • এন্ডপয়েন্ট ব্যবহার করা হয়েছে কিন্তু কনফিগার করা হয়নি। উদাহরণ:

ভুল সহ কোড
 Document-Policy: document-write=?0;report-to=endpoint-1;
 Reporting-Endpoints: default="https://reports.example/default"

ডকুমেন্ট-নীতি লঙ্ঘনের রিপোর্ট endpoint-1-এ পাঠানো উচিত, কিন্তু এই এন্ডপয়েন্টের নাম Reporting-Endpoints-এ কনফিগার করা নেই।

  • default এন্ডপয়েন্ট নেই। কিছু ধরনের রিপোর্ট, যেমন, ডেপ্রিকেশন ও ইন্টারভেনশন রিপোর্ট, শুধুমাত্র default নামের এন্ডপয়েন্টে পাঠানো হবে। রিপোর্টিং-এন্ডপয়েন্ট হেডার কনফিগার করুন লিঙ্ক থেকে আরও জানুন।

  • আপনার নীতি হেডার সিনট্যাক্সে কোনও সমস্যা আছে কিনা দেখুন, যেমন কোটেশন চিহ্ন নেই। বিবরণ দেখুন।

  • আপনার এন্ডপয়েন্ট ইনকামিং অনুরোধ ম্যানেজ করতে পারে কিনা তা চেক করুন।

    • আপনার এন্ডপয়েন্ট CORS প্রিফ্লাইট অনুরোধে কাজ করে কিনা তা নিশ্চিত করুন। যদি তা না হয়, তাহলে এটি রিপোর্ট গ্রহণ করতে পারবে না।

    • আপনার এন্ডপয়েন্টের আচরণ পরীক্ষা করুন। এটি করতে, ম্যানুয়ালি রিপোর্ট তৈরি করার পরিবর্তে, আপনি ব্রাউজারকে অনুকরণ করতে পারেন, আপনার এন্ডপয়েন্টে এমন অনুরোধ পাঠিয়ে যা ব্রাউজার যা পাঠাবে তার মতো দেখতে। নিম্নলিখিত কমান্ডগুলি চালান:

    curl --header "Content-Type: application/reports+json" \
      --request POST \
      --data '[{"age":420,"body":{"columnNumber":12,"disposition":"enforce","lineNumber":11,"message":"Document policy violation: document-write is not allowed in this document.","policyId":"document-write","sourceFile":"https://dummy.example/script.js"},"type":"document-policy-violation","url":"https://dummy.example/","user_agent":"xxx"},{"age":510,"body":{"blockedURL":"https://dummy.example/img.jpg","destination":"image","disposition":"enforce","type":"corp"},"type":"coep","url":"https://dummy.example/","user_agent":"xxx"}]' \
      YOUR_ENDPOINT
    

    আপনার এন্ডপয়েন্টকে একটি সাকসেস কোড (200 বা অন্য কোনও সাকসেস রেসপন্স কোড 2xx) দিয়ে উত্তর দিতে হবে। এটি না দিলে, সেটির কনফিগারেশনে কোনও সমস্যা আছে।

শুধু রিপোর্ট করা

-Report-Only নীতি সংক্রান্ত হেডার ও Reporting-Endpoints একসাথে কাজ করে।

Reporting-Endpoints-এ কনফিগার করা এবং Content-Security-Policy, Cross-Origin-Embedder-Policy এবং Cross-Origin-Opener-Policy-এর report-to ফিল্ডে নির্দিষ্ট করা এন্ডপয়েন্ট, এইসব নীতি লঙ্ঘন করা হলে রিপোর্ট পাবে।

Reporting-Endpoints-এ কনফিগার করা এন্ডপয়েন্টগুলি report-to ফিল্ডের Content-Security-Policy-Report-Only, Cross-Origin-Embedder-Policy-Report-Only এবং Cross-Origin-Opener-Policy-Report-Only-এও উল্লেখ করা যেতে পারে। এছাড়াও, এইসব নীতি লঙ্ঘন করা হলে তারা রিপোর্ট পাবেন।

দুটি ক্ষেত্রেই রিপোর্ট পাঠানো হলেও, -Report-Only হেডার নীতি এনফোর্স করে না: কিছুই ভাঙবে না বা আসলে ব্লক হবে না, তবে আপনি কী ভাঙবে বা ব্লক হবে তার রিপোর্ট পাবেন।

ReportingObserver

ReportingObserver জাভাস্ক্রিপ্ট API আপনাকে ক্লায়েন্ট-সাইড সতর্কতা দেখতে সাহায্য করতে পারে।

ReportingObserver এবং Reporting-Endpoints হেডার একই রকম দেখতে রিপোর্ট তৈরি করে, তবে সেগুলি সামান্য আলাদা ব্যবহারের ক্ষেত্র চালু করে।

ReportingObserver ব্যবহার করুন যদি:

  • আপনি শুধু অবলোপন বা ব্রাউজার ইন্টারভেনশন মনিটর করতে চান। ReportingObserver ক্লায়েন্ট-সাইড সতর্কতা দেখায়, যেমন ডেপ্রিকেশন এবং ব্রাউজার ইন্টারভেনশন, তবে Reporting-Endpoints-এর মতো এটি অন্য কোনও ধরনের রিপোর্ট ক্যাপচার করে না, যেমন CSP বা COOP/COEP লঙ্ঘন।
  • আপনাকে রিয়েল-টাইমে এইসব লঙ্ঘনের বিরুদ্ধে ব্যবস্থা নিতে হবে। ReportingObserver ব্যবহার করে লঙ্ঘন ইভেন্টে কলব্যাক অ্যাটাচ করা সম্ভব হয়।
  • আপনি ডিবাগিংয়ে সাহায্য করার জন্য রিপোর্টে অতিরিক্ত তথ্য যোগ করতে চান, কাস্টম কলব্যাক ব্যবহার করে।

আরেকটি পার্থক্য হল, ReportingObserver শুধুমাত্র ক্লায়েন্ট-সাইডে কনফিগার করা হয়: সার্ভার-সাইড হেডারের উপর আপনার নিয়ন্ত্রণ না থাকলেও এবং Reporting-Endpoints সেট করতে না পারলেও আপনি এটি ব্যবহার করতে পারবেন।

আরও পড়ুন

এই ডকুমেন্ট সম্পর্কে মতামত ও সাজেশন দেওয়ার জন্য ইয়ান ক্লিল্যান্ড, এইজি কিটামুরা ও মিলিকা মিহাইলিয়াকে ধন্যবাদ।