CORS পরীক্ষক

একটি পেস্ট করা প্রতিক্রিয়া একটি নির্দিষ্ট ব্রাউজার উত্স, পদ্ধতি এবং অনুরোধ শিরোনাম অনুমোদন করে কিনা তা পরীক্ষা করুন৷

চেক করার প্রতিক্রিয়া
প্রিফ্লাইট প্রতিক্রিয়া চেক করার সময় স্ট্যাটাস লাইনটিও পেস্ট করুন।
স্কিম, হোস্ট এবং ঐচ্ছিক পোর্ট অরিজিন হেডারে পাঠানো হয়েছে।
কুকি বা HTTP প্রমাণীকরণ অন্তর্ভুক্ত অনুরোধের জন্য চালু করুন।
ব্রাউজার সিদ্ধান্ত

    পার্সড এক্সেস-কন্ট্রোল ক্ষেত্র

    HTTP status
    Access-Control-Allow-Origin
    Access-Control-Allow-Credentials
    Access-Control-Allow-Methods
    Access-Control-Allow-Headers
    Access-Control-Expose-Headers
    Access-Control-Max-Age

    একটি প্রতিক্রিয়া লিখুন এবং বিশদ বিবরণের অনুরোধ করুন, তারপর CORS নীতি পরীক্ষা করুন৷

    এর CORS নীতি চেক করতে একটি প্রতিক্রিয়া পেস্ট করুন।

    আপনার শিরোনাম এবং অনুরোধের বিবরণ আপনার ব্রাউজারে থাকে। BroBroGo দ্বারা কিছুই আপলোড করা বা সংরক্ষণ করা হয় না।

    জিজ্ঞাসিত প্রশ্নাবলী

    আমি কি প্রকৃত প্রতিক্রিয়া বা প্রিফ্লাইট প্রতিক্রিয়া পেস্ট করব?

    ব্রাউজার কোড একটি প্রতিক্রিয়া পড়তে পারে কিনা তা পরীক্ষা করতে প্রকৃত প্রতিক্রিয়া ব্যবহার করুন। OPTIONS উত্তরের জন্য প্রিফ্লাইট প্রতিক্রিয়া ব্যবহার করুন যা পরবর্তী পদ্ধতি এবং তার অনুরোধ করা শিরোনামের নাম অনুমোদন করে।

    কেন একটি ওয়াইল্ডকার্ড শংসাপত্রের সাথে ব্যর্থ হতে পারে?

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

    একটি পাসিং ফলাফল প্রমাণ করে যে লাইভ অনুরোধ কাজ করবে?

    না। এই ফলাফলটি শুধুমাত্র পেস্ট করা প্রতিক্রিয়া এবং অনুরোধের বিশদ এখানে প্রবেশ করানো হয়েছে। পুনঃনির্দেশ, ক্যাশে করা প্রতিক্রিয়া, সার্ভারের নিয়ম পরিবর্তন, ব্রাউজার এক্সটেনশন এবং একটি প্রিফ্লাইটের পরে প্রকৃত প্রতিক্রিয়া এখনও ফলাফল পরিবর্তন করতে পারে।

    CORS নীতি এবং ব্রাউজার সিদ্ধান্তের বিশ্লেষণ

    ক্রস-অরিজিন রিসোর্স শেয়ারিং (CORS) হলো ব্রাউজারের একটি নিরাপত্তা ব্যবস্থা যা একটি ওয়েব অ্যাপ্লিকেশনকে ভিন্ন কোনো উৎসের (origin) রিসোর্স অ্যাক্সেস করার অনুমতি দেয়। ব্রাউজার কোড কোনো নির্দিষ্ট প্রতিক্রিয়া পড়তে পারবে কিনা তা নির্ধারণ করতে এই নীতি কঠোরভাবে প্রয়োগ করা হয়। "CORS পরীক্ষক" টুলটি আপনার প্রদান করা HTTP রেসপন্স হেডার এবং অনুরোধের বিবরণের উপর ভিত্তি করে ব্রাউজারের আচরণ বিশ্লেষণ করে।

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

    ইনপুট প্যারামিটার এবং কনফিগারেশন

    টুলটি সঠিকভাবে ব্যবহার করার জন্য আপনাকে নির্দিষ্ট কিছু ইনপুট প্রদান করতে হবে:

    • চেক করার প্রতিক্রিয়া: এখানে আপনাকে "প্রকৃত প্রতিক্রিয়া" অথবা "প্রিফ্লাইট প্রতিক্রিয়া" এর মধ্যে একটি বেছে নিতে হবে।
    • HTTP প্রতিক্রিয়া শিরোনাম: এই টেক্সট বক্সে রেসপন্স হেডারগুলো পেস্ট করতে হবে। প্রিফ্লাইট প্রতিক্রিয়ার ক্ষেত্রে স্ট্যাটাস লাইনটিও অন্তর্ভুক্ত করা প্রয়োজন। ইনপুটের সর্বোচ্চ দৈর্ঘ্য ২০০,০০০ অক্ষর।
    • উত্স অনুরোধ: যে উৎস থেকে অনুরোধটি পাঠানো হচ্ছে তার স্কিম, হোস্ট এবং ঐচ্ছিক পোর্ট এখানে লিখতে হবে (যেমন: https://app.example.com)। এটি অবশ্যই একটি বিশুদ্ধ উৎস বা null হতে হবে; কোনো ইউআরএল পাথ, কুয়েরি বা শংসাপত্র থাকা যাবে না।
    • অনুরোধ করা পদ্ধতি: অনুরোধের জন্য ব্যবহৃত HTTP পদ্ধতি (যেমন: GET, POST) এখানে উল্লেখ করতে হবে।
    • হেডার নাম অনুরোধ করা হয়েছে: Access-Control-Request-Headers থেকে প্রাপ্ত হেডারগুলোর নাম কমা বা লাইন দ্বারা বিভক্ত করে লিখতে হবে (যেমন: Content-Type, Authorization)।
    • শংসাপত্রগুলি অন্তর্ভুক্ত করুন: অনুরোধে কুকি বা HTTP প্রমাণীকরণ অন্তর্ভুক্ত থাকলে এই টগলটি চালু করতে হবে।

    ইনপুট প্রক্রিয়াকরণের সময় কোনো সমস্যা হলে টুলটি "হাইলাইট করা ইনপুট ঠিক করুন এবং আবার চেষ্টা করুন।" ত্রুটি বার্তাটি প্রদর্শন করে।

    CORS নীতিতে শংসাপত্র এবং ওয়াইল্ডকার্ডের নিয়ম

    CORS নীতিতে শংসাপত্র (credentials) এবং ওয়াইল্ডকার্ড (*) চিহ্নের ব্যবহার অত্যন্ত সংবেদনশীল। যখন অনুরোধে শংসাপত্র অন্তর্ভুক্ত করা হয়, তখন ব্রাউজার নিম্নলিখিত নিয়মগুলো কঠোরভাবে প্রয়োগ করে:

    1. উৎস যাচাইকরণ: শংসাপত্র অন্তর্ভুক্ত থাকলে Access-Control-Allow-Origin হেডারটির মান ওয়াইল্ডকার্ড * হতে পারবে না। এটি অবশ্যই অনুরোধকারী উৎসের সাথে হুবহু মিলতে হবে।
    2. পদ্ধতি এবং হেডার: শংসাপত্র সহ অনুরোধের ক্ষেত্রে অনুমোদিত পদ্ধতি এবং হেডারগুলোর জন্য ওয়াইল্ডকার্ডগুলো তাদের ওয়াইল্ডকার্ডের অর্থ হারিয়ে ফেলে।
    3. শংসাপত্র অনুমোদন: শংসাপত্রযুক্ত অনুরোধের জন্য প্রতিক্রিয়া হেডারে অবশ্যই Access-Control-Allow-Credentials: true থাকতে হবে।

    যদি কোনো শংসাপত্র অন্তর্ভুক্ত না থাকে, তবে Access-Control-Allow-Methods এবং Access-Control-Allow-Headers এর জন্য ওয়াইল্ডকার্ড * ব্যবহার করা যেতে পারে। তবে Authorization হেডারের ক্ষেত্রে বিশেষ নিয়ম প্রযোজ্য।

    প্রিফ্লাইট প্রতিক্রিয়া এবং বিশেষ হেডার যাচাইকরণ

    একটি প্রকৃত অনুরোধ পাঠানোর আগে ব্রাউজার প্রায়শই একটি OPTIONS অনুরোধ পাঠায়, যাকে প্রিফ্লাইট (preflight) অনুরোধ বলা হয়। এই প্রিফ্লাইট প্রতিক্রিয়ার বৈধতা যাচাই করার জন্য কিছু নির্দিষ্ট নিয়ম রয়েছে:

    • HTTP স্ট্যাটাস কোড: প্রিফ্লাইট প্রতিক্রিয়ার জন্য একটি সফল 2xx স্ট্যাটাস কোড থাকা আবশ্যক। যদি কোনো HTTP স্ট্যাটাস লাইন পেস্ট করা না হয়, তবে প্রয়োজনীয় প্রিফ্লাইট স্ট্যাটাস পরীক্ষা করা যায় না।
    • পদ্ধতি অনুমোদন: অনুরোধ করা পদ্ধতিটি যদি CORS-নিরাপদ (CORS-safelisted) পদ্ধতি না হয়, তবে সেটি অবশ্যই Access-Control-Allow-Methods হেডারে তালিকাভুক্ত থাকতে হবে।
    • Authorization হেডারের নিয়ম: Authorization হেডারটি অত্যন্ত সংবেদনশীল হওয়ায় এটিকে সর্বদা স্পষ্টভাবে Access-Control-Allow-Headers-এ তালিকাভুক্ত করতে হবে। Access-Control-Allow-Headers: * ওয়াইল্ডকার্ডটি শংসাপত্রহীন অনুরোধের ক্ষেত্রে অন্যান্য হেডার কভার করলেও Authorization হেডারকে কভার করে না।

    ব্রাউজার সিদ্ধান্তের ফলাফল এবং কারণসমূহ

    টুলটি ইনপুট বিশ্লেষণ করে ব্রাউজারের সিদ্ধান্ত এবং তার পেছনের সুনির্দিষ্ট কারণগুলো প্রদর্শন করে।

    ব্রাউজার সিদ্ধান্তের লেবেলসমূহ:

    • "আটকানো CORS প্রতিক্রিয়া দ্বারা অনুমোদিত৷"
    • "আটকানো CORS প্রতিক্রিয়া দ্বারা অবরুদ্ধ৷"
    • "হেডার পাস, কিন্তু প্রিফ্লাইট স্ট্যাটাস অজানা।"
    • "একটি প্রতিক্রিয়া লিখুন এবং বিশদ বিবরণের অনুরোধ করুন, তারপর CORS নীতি পরীক্ষা করুন৷" (যখন কোনো ইনপুট থাকে না)
    • "এর CORS নীতি চেক করতে একটি প্রতিক্রিয়া পেস্ট করুন।" (প্রাথমিক অবস্থা)

    সিদ্ধান্তের কারণসমূহ (টেবিল):

    ক্ষেত্র বিশ্লেষণের ফলাফল এবং প্রদর্শিত বার্তা
    উৎস (Origin) Access-Control-Allow-Origin হুবহু ‹origin› এর সাথে মেলে।<br>Access-Control-Allow-Origin এই অনুরোধের জন্য যেকোন উৎসের অনুমতি দেয়।<br>Access-Control-Allow-Origin অনুপস্থিত৷<br>শংসাপত্রগুলি অন্তর্ভুক্ত করা হলে Access-Control-Allow-Origin * হতে পারে না৷<br>Access-Control-Allow-Origin হল ‹actual›, ‹expected› নয়।<br>Access-Control-Allow-Origin এর একটি অবৈধ মান আছে: ‹value›।
    শংসাপত্র (Credentials) Access-Control-Allow-Credentials ঠিক সত্য।<br>একটি শংসাপত্রযুক্ত অনুরোধের প্রয়োজন Access-Control-Allow-Credentials: সত্য৷<br>শংসাপত্রগুলি অন্তর্ভুক্ত নয়, তাই Access-Control-Allow-Credentials এই সিদ্ধান্তকে প্রভাবিত করে না৷
    প্রিফ্লাইট স্ট্যাটাস প্রিফ্লাইট স্ট্যাটাস ‹status› সফল।<br>প্রিফ্লাইট স্ট্যাটাস ‹status› একটি সফল 2xx স্ট্যাটাস নয়।<br>কোনো HTTP স্ট্যাটাস লাইন পেস্ট করা হয়নি, তাই প্রয়োজনীয় 2xx প্রিফ্লাইট স্ট্যাটাস চেক করা যাবে না।
    অনুরোধের পদ্ধতি প্রিফ্লাইট ‹method› অনুমতি দেয়।<br>‹method› হল একটি CORS-নিরাপদ পদ্ধতি এবং Access-Control-Allow-Methods-এ উপস্থিত হওয়ার প্রয়োজন নেই৷<br>Access-Control-Allow-Methods ‹method› অনুমতি দেয় না।
    অনুরোধের হেডার কোন অনুরোধ করা শিরোনাম নাম preflight অনুমোদন প্রয়োজন.<br>প্রিফ্লাইট অনুরোধ করা শিরোনামের নামগুলিকে অনুমতি দেয়: ‹headers›।<br>Access-Control-Allow-Headers: * শংসাপত্র ছাড়াই একটি অনুরোধের জন্য এই নামগুলি কভার করে: ‹headers›৷<br>Access-Control-Allow-Headers অনুমতি দেয় না: ‹headers›।<br>Authorization স্পষ্টভাবে তালিকাভুক্ত করা আবশ্যক; Access-Control-Allow-Headers: * এটি কভার করে না।

    প্রায়শই জিজ্ঞাসিত প্রশ্ন (FAQ)

    আমি কি প্রকৃত প্রতিক্রিয়া বা প্রিফ্লাইট প্রতিক্রিয়া পেস্ট করব?
    ব্রাউজার কোড একটি প্রতিক্রিয়া পড়তে পারে কিনা তা পরীক্ষা করতে প্রকৃত প্রতিক্রিয়া ব্যবহার করুন। OPTIONS উত্তরের জন্য প্রিফ্লাইট প্রতিক্রিয়া ব্যবহার করুন যা পরবর্তী পদ্ধতি এবং তার অনুরোধ করা শিরোনামের নাম অনুমোদন করে।

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

    একটি পাসিং ফলাফল প্রমাণ করে যে লাইভ অনুরোধ কাজ করবে?
    না। এই ফলাফলটি শুধুমাত্র পেস্ট করা প্রতিক্রিয়া এবং অনুরোধের বিশদ এখানে প্রবেশ করানো হয়েছে। পুনঃনির্দেশ, ক্যাশে করা প্রতিক্রিয়া, সার্ভারের নিয়ম পরিবর্তন, ব্রাউজার এক্সটেনশন এবং একটি প্রিফ্লাইটের পরে প্রকৃত প্রতিক্রিয়া এখনও ফলাফল পরিবর্তন করতে পারে।

    ইনপুট দেওয়ার সময় কী কী ত্রুটি বার্তা দেখা যেতে পারে?
    ভুল ইনপুটের ক্ষেত্রে টুলটি নির্দিষ্ট কিছু ত্রুটি প্রদর্শন করে, যেমন:

    • "চেক করার আগে HTTP প্রতিক্রিয়া শিরোনাম আটকান।"
    • "এই প্রতিক্রিয়া অস্বাভাবিকভাবে বড়। এটি ‹max› অক্ষরের অধীনে রাখুন।"
    • "লাইন ‹line› একটি বৈধ HTTP হেডার বা স্ট্যাটাস লাইন নয়।"
    • "‹line› লাইনে একটি অবৈধ HTTP হেডার নাম রয়েছে৷"
    • "শুধুমাত্র একটি স্কিম, হোস্ট এবং ঐচ্ছিক পোর্ট সহ একটি মূল লিখুন, যেমন https://app.example.com।"
    • "একটি বৈধ HTTP পদ্ধতি টোকেন লিখুন।"
    • "ব্রাউজার fetch অনুরোধে ‹method› পদ্ধতির অনুমতি দেয় না।"
    • ""‹header›" একটি বৈধ HTTP অনুরোধ শিরোনামের নাম নয়৷"