এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

রিপোর্টিং API এর মাধ্যমে আপনার ওয়েব অ্যাপ্লিকেশন নিরীক্ষণ করুন

নিরাপত্তা লঙ্ঘন, অপ্রচলিত এপিআই কল এবং আরও অনেক কিছু নিরীক্ষণ করতে রিপোর্টিং এপিআই ব্যবহার করুন।

Maud Nalpas

সতর্কতা:

এটি রিপোর্টিং এপিআই (v1)- এর একটি এপিআই গাইড, যেখানে এর ব্যবহারের বিস্তারিত উদাহরণ দেওয়া হয়েছে এবং এটি Reporting-Endpoints হেডার ব্যবহার করে।

আপনি যদি লিগ্যাসি রিপোর্টিং এপিআই ( Report-To হেডার) ব্যবহার করে থাকেন, তাহলে এর পরিবর্তে এপিআই মাইগ্রেশন সম্পর্কে পড়ুন।

আপনি কি নেটওয়ার্ক ত্রুটি লগিং-এর ডকুমেন্টেশন খুঁজছেন? তাহলে এর পরিবর্তে নেটওয়ার্ক ত্রুটি লগিং-এ যান।

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

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

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

এই পোস্টে আলোচনা করা হয়েছে এই এপিআইটি কী করতে পারে এবং কীভাবে এটি ব্যবহার করতে হয়। চলুন শুরু করা যাক!

সংক্ষিপ্ত বিবরণ

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

ধরা যাক, আপনার সাইট 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"
}

ব্যবহারের ক্ষেত্র এবং প্রতিবেদনের প্রকারভেদ

আপনার সাইট জুড়ে ঘটে যাওয়া বিভিন্ন ধরণের গুরুত্বপূর্ণ সতর্কতা বা সমস্যা নিরীক্ষণ করতে রিপোর্টিং এপিআই কনফিগার করা যেতে পারে:

রিপোর্টের ধরণ	এমন একটি পরিস্থিতির উদাহরণ যেখানে একটি প্রতিবেদন তৈরি হবে
সিএসপি লঙ্ঘন (শুধুমাত্র লেভেল ৩ এর জন্য)	আপনি আপনার একটি পেজে `Content-Security-Policy` (CSP) সেট করেছেন, কিন্তু পেজটি এমন একটি স্ক্রিপ্ট লোড করার চেষ্টা করছে যা আপনার CSP দ্বারা অনুমোদিত নয়।
সমবায় লঙ্ঘন	আপনি একটি পৃষ্ঠায় `Cross-Origin-Opener-Policy` সেট করেছেন, কিন্তু একটি ক্রস-অরিজিন উইন্ডো সরাসরি ডকুমেন্টটির সাথে ইন্টারঅ্যাক্ট করার চেষ্টা করছে।
COEP লঙ্ঘন	আপনি একটি পৃষ্ঠায় `Cross-Origin-Embedder-Policy` সেট করেছেন, কিন্তু ডকুমেন্টটিতে একটি ক্রস-অরিজিন আইফ্রেম অন্তর্ভুক্ত রয়েছে যা ক্রস-অরিজিন ডকুমেন্ট দ্বারা লোড হওয়ার জন্য সম্মতি দেয়নি।
নথি নীতি লঙ্ঘন	পেজটিতে এমন একটি ডকুমেন্ট পলিসি আছে যা `document.write` এর ব্যবহার প্রতিরোধ করে, কিন্তু একটি স্ক্রিপ্ট `document.write` কল করার চেষ্টা করছে।
অনুমতি নীতি লঙ্ঘন	পেজটিতে এমন একটি অনুমতি নীতি রয়েছে যা মাইক্রোফোন ব্যবহারে বাধা দেয় এবং এমন একটি স্ক্রিপ্ট রয়েছে যা অডিও ইনপুটের অনুরোধ করে।
অবমূল্যায়ন সতর্কতা	পৃষ্ঠাটি এমন একটি এপিআই ব্যবহার করছে যা অপ্রচলিত বা শীঘ্রই অপ্রচলিত হয়ে যাবে; এটি সরাসরি অথবা একটি শীর্ষ-স্তরের তৃতীয়-পক্ষের স্ক্রিপ্ট ব্যবহার করে সেটিকে কল করে।
হস্তক্ষেপ	পৃষ্ঠাটি এমন কিছু করার চেষ্টা করছে যা ব্রাউজার নিরাপত্তা, কর্মক্ষমতা বা ব্যবহারকারীর অভিজ্ঞতার কারণে সমর্থন না করার সিদ্ধান্ত নেয়। ক্রোমের ক্ষেত্রে উদাহরণ: পৃষ্ঠাটি ধীরগতির নেটওয়ার্কে `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 স্ট্রিং-এ সিরিয়ালাইজ করা হয়েছে। একটি রিপোর্টের `body` থাকা ফিল্ডগুলো রিপোর্টের `type` দ্বারা নির্ধারিত হয়। ⚠️ বিভিন্ন টাইপের রিপোর্টের বডি ভিন্ন ভিন্ন হয় ।
`type`	রিপোর্টের ধরণ, যেমন `csp-violation` বা `coep` ।
`url`	যে নথি বা কর্মীর ঠিকানা থেকে প্রতিবেদনটি তৈরি করা হয়েছে। এই URL থেকে ব্যবহারকারীর নাম, পাসওয়ার্ড এবং খণ্ডাংশের মতো সংবেদনশীল তথ্য মুছে ফেলা হয়।
`user_agent`	যে অনুরোধ থেকে প্রতিবেদনটি তৈরি করা হয়েছিল, তার `User-Agent` হেডার।

প্রমাণপত্র প্রতিবেদন

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

ব্যবহারকারীর পরিচয়পত্র রিপোর্টটি সম্পর্কে প্রয়োজনীয় অতিরিক্ত তথ্য দিতে পারে; যেমন, কোনো নির্দিষ্ট ব্যবহারকারীর অ্যাকাউন্ট ধারাবাহিকভাবে ত্রুটি সৃষ্টি করছে কিনা, অথবা অন্য পেজগুলোতে নেওয়া কোনো নির্দিষ্ট ধারাবাহিক কার্যকলাপ এই পেজে একটি রিপোর্ট তৈরি করছে কিনা।

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

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

এর মানে হলো, রিপোর্টিং এপিআই ব্যবহার করার ক্ষেত্রে পারফরম্যান্স নিয়ে উদ্বেগের তেমন কোনো কারণ নেই।

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

তৃতীয়-পক্ষ এবং প্রথম-পক্ষের সমস্যা

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

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

অপ্রচলিত উদাহরণ

আপনার পেজে যদি Reporting-Endpoints হেডার সেট আপ করা থাকে, তাহলে আপনার পেজে চলমান থার্ড-পার্টি স্ক্রিপ্ট দ্বারা কল করা ডেপ্রিকেটেড API আপনার এন্ডপয়েন্টে রিপোর্ট করা হবে। আপনার পেজে এমবেড করা কোনো আইফ্রেম দ্বারা কল করা ডেপ্রিকেটেড API আপনার এন্ডপয়েন্টে রিপোর্ট করা হবে না। একটি ডেপ্রিকেশন রিপোর্ট শুধুমাত্র তখনই তৈরি হবে যদি আইফ্রেম সার্ভার Reporting-Endpoints সেট আপ করে থাকে, এবং এই রিপোর্টটি আইফ্রেমের সার্ভার দ্বারা সেট আপ করা এন্ডপয়েন্টে পাঠানো হবে।

ব্রাউজার সমর্থন

নিম্নলিখিত সারণীতে রিপোর্টিং এপিআই ভি১ (Reporting API v1) -এর জন্য ব্রাউজার সমর্থনের সারসংক্ষেপ দেওয়া হয়েছে, যা Reporting-Endpoints ) হেডারের সাথে ব্যবহৃত হয়। রিপোর্টিং এপিআই ভি০ ( Report-To হেডার)-এর জন্য ব্রাউজার সমর্থন একই, তবে একটি রিপোর্ট টাইপের ক্ষেত্রে ব্যতিক্রম রয়েছে: নতুন রিপোর্টিং এপিআই-তে নেটওয়ার্ক এরর লগিং (Network Error Logging) সমর্থিত নয়। বিস্তারিত জানতে মাইগ্রেশন গাইডটি পড়ুন।

রিপোর্টের ধরণ	ক্রোম	ক্রোম আইওএস	সাফারি	ফায়ারফক্স	প্রান্ত
সিএসপি লঙ্ঘন (শুধুমাত্র লেভেল ৩ এর জন্য)*	✔ হ্যাঁ	✔ হ্যাঁ	✔ হ্যাঁ	✘ না	✔ হ্যাঁ
নেটওয়ার্ক ত্রুটি লগিং	✘ না	✘ না	✘ না	✘ না	✘ না
COOP/COEP লঙ্ঘন	✔ হ্যাঁ	✘ না	✔ হ্যাঁ	✘ না	✔ হ্যাঁ
অন্যান্য সকল প্রকার: নথি নীতি লঙ্ঘন, অবচয়, হস্তক্ষেপ, ক্র্যাশ	✔ হ্যাঁ	✘ না	✘ না	✘ না	✔ হ্যাঁ

সতর্কতা:

অন্যান্য রিপোর্টিং প্রকারের থেকে CSP রিপোর্টিং-এর জন্য ব্রাউজার সমর্থন ভিন্ন, কারণ CSP বেশ কিছু সময় ধরে প্রচলিত আছে। নিম্নলিখিত পদ্ধতি ব্যবহার করে CSP রিপোর্ট তৈরি করা যেতে পারে:

লিগ্যাসি report-uri ডিরেক্টিভ যা রিপোর্টিং এপিআই-এর উপর নির্ভর করে না।
নতুন report-to ডিরেক্টিভটি রিপোর্টিং এপিআই (এবং Reporting-To বা নতুন Reporting-Endpoints হেডার)-এর উপর নির্ভর করে।

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

রিপোর্টিং এপিআই ব্যবহার করে

রিপোর্টগুলো কোথায় পাঠানো উচিত তা নির্ধারণ করুন

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

বিদ্যমান কোনো রিপোর্ট সংগ্রহকারী পরিষেবাতে রিপোর্টগুলো পাঠান।
আপনার নিজের তৈরি ও পরিচালিত একটি রিপোর্টিং কালেক্টরে রিপোর্ট পাঠান।

বিকল্প ১: একটি বিদ্যমান প্রতিবেদন সংগ্রহকারী পরিষেবা ব্যবহার করুন

প্রতিবেদন সংগ্রহকারী পরিষেবার কিছু উদাহরণ হলো:

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

মূল্যের পাশাপাশি, রিপোর্ট সংগ্রাহক নির্বাচন করার সময় নিম্নলিখিত বিষয়গুলো বিবেচনা করুন: 🧐

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

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

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

যখন আপনি আপনার নিজস্ব রিপোর্ট সংগ্রাহক তৈরি করেন:

ব্রাউজার থেকে আপনার এন্ডপয়েন্টে পাঠানো রিপোর্ট রিকোয়েস্টগুলো শনাক্ত করতে, 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"

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

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 এন্ডপয়েন্ট নির্ধারণ করা না থাকে, তাহলে এই ধরনের রিপোর্ট পাঠানো হবে না (যদিও সেগুলি তৈরি হবে)।

মূল বিষয়: এর নাম সত্ত্বেও, default কোনো ফলব্যাক এন্ডপয়েন্ট নয় । উদাহরণস্বরূপ, যদি আপনি Document-Policy জন্য report-to my-endpoint ' সেট আপ করেন এবং Reporting-Endpoints এ my-endpoint সংজ্ঞায়িত করতে ভুলে যান, তাহলে Document-Policy লঙ্ঘনের রিপোর্ট তৈরি হবে ঠিকই, কিন্তু সেগুলো পাঠানো হবে না , কারণ ব্রাউজার জানে না যে সেগুলো কোথায় পাঠাতে হবে।

মান (ইউআরএল)

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

একটি এন্ডপয়েন্ট ইউআরএল:

অবশ্যই একটি স্ল্যাশ ( / ) দিয়ে শুরু করতে হবে। রিলেটিভ পাথ সমর্থিত নয় ।
এটি ক্রস-অরিজিন হতে পারে; কিন্তু সেক্ষেত্রে রিপোর্টের সাথে ক্রেডেনশিয়াল পাঠানো হয় না ।

উদাহরণ

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

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

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

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

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

এক্সপ্রেসে একটি উদাহরণ দেওয়া হলো:

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();
});

দ্রষ্টব্য: এটি লিগ্যাসি রিপোর্টিং এপিআই ( Report-To হেডার) থেকে ভিন্ন, যেখানে আপনি একটি পেজের জন্য একটি "অ্যাম্বিয়েন্ট" এন্ডপয়েন্ট সেট করে একই অরিজিনের যেকোনো পেজের জন্য স্বয়ংক্রিয়ভাবে রিপোর্ট পেতে পারতেন। আপনি যদি লিগ্যাসি রিপোর্টিং এপিআই থেকে নতুন রিপোর্টিং এপিআই-তে মাইগ্রেট করেন, তাহলে মাইগ্রেশন গাইডটি দেখুন।

আপনার নীতিমালা সম্পাদনা করুন

এখন যেহেতু 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

সতর্কতা: report-to সিনট্যাক্সটি সঠিকভাবে ব্যবহার করা বেশ কঠিন হতে পারে, কারণ সব পলিসি একই হেডার কাঠামো ব্যবহার করে না। পলিসির উপর নির্ভর করে, সঠিক সিনট্যাক্সটি report-to=main-endpoint অথবা report-to main-endpoint হতে পারে।

আপনার রিপোর্টিং সেটআপ ডিবাগ করুন

ইচ্ছাকৃতভাবে প্রতিবেদন তৈরি করুন

রিপোর্টিং এপিআই সেট আপ করার সময়, রিপোর্টগুলো প্রত্যাশা অনুযায়ী তৈরি ও পাঠানো হচ্ছে কিনা তা পরীক্ষা করার জন্য আপনাকে সম্ভবত ইচ্ছাকৃতভাবে আপনার নীতিমালা লঙ্ঘন করতে হবে।

সময় বাঁচান

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

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

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

ডেভটুলস ব্যবহার করুন

ক্রোমে, পাঠানো হয়েছে বা পাঠানো হবে এমন রিপোর্টগুলো দেখতে ডেভটুলস ব্যবহার করুন।

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

ক্রোম ভার্সন ৯৬ এবং তার পরবর্তী সংস্করণ ব্যবহার করুন (আপনার ব্রাউজারে chrome://version টাইপ করে যাচাই করুন)।
ক্রোমের অ্যাড্রেস বারে chrome://flags/#enable-experimental-web-platform-features টাইপ বা পেস্ট করুন।
সক্ষম-এ ক্লিক করুন।
আপনার ব্রাউজারটি পুনরায় চালু করুন।
ক্রোম ডেভটুলস খুলুন।
Chrome DevTools-এ, Settings খুলুন। Experiments-এর অধীনে, Application প্যানেলে থাকা Enable Reporting API প্যানেলটিতে ক্লিক করুন।
DevTools পুনরায় লোড করুন।
আপনার পৃষ্ঠাটি পুনরায় লোড করুন। DevTools যে পৃষ্ঠায় খোলা আছে, সেই পৃষ্ঠা দ্বারা তৈরি রিপোর্টগুলি Chrome DevTools-এর অ্যাপ্লিকেশন প্যানেলে, রিপোর্টিং এপিআই (Reporting API) -এর অধীনে তালিকাভুক্ত হবে।

ডেভটুলস-এর রিপোর্ট তালিকা সম্বলিত স্ক্রিনশট। — ক্রোম ডেভটুলস আপনার পেজে তৈরি হওয়া রিপোর্টগুলো এবং সেগুলোর অবস্থা প্রদর্শন করে।

রিপোর্টের অবস্থা

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

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

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

মূল বিষয়: Queued স্ট্যাটাসটি সবসময় তথ্যপূর্ণ হয় না, কারণ এটি স্পষ্টভাবে নির্দেশ করে না যে পাঠানো ব্যর্থ হয়েছে নাকি এখনও চেষ্টা করা হয়নি। রিপোর্টিং-এ কম বিলম্ব ব্যবহার করলে সুবিধা হয়: সেক্ষেত্রে, একটি রিপোর্ট Queued অবস্থায় থাকলে সম্ভবত বোঝা যায় যে পাঠানো ব্যর্থ হচ্ছে।

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

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

রিপোর্ট তৈরি করা হয় না

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

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

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

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

গুরুত্বপূর্ণ বিষয়: যেহেতু রিপোর্টটি কোনো নির্দিষ্ট সাইটের মাধ্যমে নয়, বরং ব্রাউজার নিজেই আউট-অফ-ব্যান্ডে পাঠায়, তাই রিপোর্ট সম্বলিত POST রিকোয়েস্টগুলো আপনার ডেভেলপার টুলসের নেটওয়ার্ক প্যানেলে প্রদর্শিত হয় না।

কম বিলম্ব ব্যবহার করতে ভুলবেন না। হতে পারে আপনি রিপোর্টটি দেখতে পাচ্ছেন না কারণ এটি এখনও পাঠানো হয়নি!
আপনার 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 নামের এন্ডপয়েন্টে পাঠানো হবে। 'Reporting-Endpoints' হেডার কনফিগার করুন অংশে আরও পড়ুন।
আপনার পলিসি হেডারের সিনট্যাক্সে কোনো সমস্যা আছে কিনা দেখুন, যেমন কোটেশন চিহ্ন অনুপস্থিত থাকা। বিস্তারিত দেখুন ।
আপনার এন্ডপয়েন্টটি আগত অনুরোধগুলি পরিচালনা করতে সক্ষম কিনা তা যাচাই করুন।
- নিশ্চিত করুন যে আপনার এন্ডপয়েন্ট 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 ) দিয়ে সাড়া দেওয়া উচিত। যদি তা না হয়, তাহলে এর কনফিগারেশনে কোনো সমস্যা আছে।

রিপোর্টিং API এর মাধ্যমে আপনার ওয়েব অ্যাপ্লিকেশন নিরীক্ষণ করুন

সংক্ষিপ্ত বিবরণ

ব্যবহারের ক্ষেত্র এবং প্রতিবেদনের প্রকারভেদ

প্রতিবেদন

রিপোর্টগুলো দেখতে কেমন হয়?

প্রমাণপত্র প্রতিবেদন

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

তৃতীয়-পক্ষ এবং প্রথম-পক্ষের সমস্যা

অপ্রচলিত উদাহরণ

ব্রাউজার সমর্থন

রিপোর্টিং এপিআই ব্যবহার করে

রিপোর্টগুলো কোথায় পাঠানো উচিত তা নির্ধারণ করুন

বিকল্প ১: একটি বিদ্যমান প্রতিবেদন সংগ্রহকারী পরিষেবা ব্যবহার করুন

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

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

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

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

মান (ইউআরএল)

উদাহরণ

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

আপনার নীতিমালা সম্পাদনা করুন

উদাহরণ

আপনার রিপোর্টিং সেটআপ ডিবাগ করুন

ইচ্ছাকৃতভাবে প্রতিবেদন তৈরি করুন

সময় বাঁচান

ডেভটুলস ব্যবহার করুন

রিপোর্টের অবস্থা

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

রিপোর্ট তৈরি করা হয় না

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

সম্পর্কিত রিপোর্টিং প্রক্রিয়া

শুধুমাত্র রিপোর্ট

`ReportingObserver`

আরও পড়ুন

সংক্ষিপ্ত বিবরণ

ব্যবহারের ক্ষেত্র এবং প্রতিবেদনের প্রকারভেদ

প্রতিবেদন

রিপোর্টগুলো দেখতে কেমন হয়?

প্রমাণপত্র প্রতিবেদন

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

তৃতীয়-পক্ষ এবং প্রথম-পক্ষের সমস্যা

অপ্রচলিত উদাহরণ

ব্রাউজার সমর্থন

রিপোর্টিং এপিআই ব্যবহার করে

রিপোর্টগুলো কোথায় পাঠানো উচিত তা নির্ধারণ করুন

বিকল্প ১: একটি বিদ্যমান প্রতিবেদন সংগ্রহকারী পরিষেবা ব্যবহার করুন

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

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

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

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

মান (ইউআরএল)

উদাহরণ

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

আপনার নীতিমালা সম্পাদনা করুন

উদাহরণ

আপনার রিপোর্টিং সেটআপ ডিবাগ করুন

ইচ্ছাকৃতভাবে প্রতিবেদন তৈরি করুন

সময় বাঁচান

ডেভটুলস ব্যবহার করুন

রিপোর্টের অবস্থা

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

রিপোর্ট তৈরি করা হয় না

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

সম্পর্কিত রিপোর্টিং প্রক্রিয়া

শুধুমাত্র রিপোর্ট

ReportingObserver

আরও পড়ুন

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

`ReportingObserver`