CORS ചെക്കർ

പ്രതികരണം origin, method, request headers എന്നിവ അനുവദിക്കുന്നുണ്ടോ പരിശോധിക്കുക.

പരിശോധിക്കുന്നതിനുള്ള പ്രതികരണം
ഒരു പ്രിഫ്ലൈറ്റ് പ്രതികരണം പരിശോധിക്കുമ്പോൾ സ്റ്റാറ്റസ് ലൈൻ ഒട്ടിക്കുക.
Origin ഹെഡറിൽ അയച്ച സ്കീമും ഹോസ്റ്റും ഓപ്ഷണൽ പോർട്ടും.
കുക്കികൾ അല്ലെങ്കിൽ 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 പ്രാമാണീകരണം ഉൾപ്പെടുത്തുമ്പോൾ, അനുവദനീയമായ ഉറവിടം അഭ്യർത്ഥിക്കുന്ന ഉറവിടവുമായി കൃത്യമായി പൊരുത്തപ്പെടണം. അനുവദനീയമായ രീതികൾക്കും ഹെഡറുകൾക്കുമുള്ള വൈൽഡ്കാർഡുകൾക്കും അവയുടെ വൈൽഡ്കാർഡ് അർത്ഥം നഷ്ടപ്പെടും.

    തത്സമയ അഭ്യർത്ഥന പ്രവർത്തിക്കുമെന്ന് പാസിംഗ് ഫലം തെളിയിക്കുന്നുണ്ടോ?

    ഇല്ല. ഈ ഫലം ഒട്ടിച്ച പ്രതികരണവും ഇവിടെ നൽകിയ അഭ്യർത്ഥന വിശദാംശങ്ങളും മാത്രം ഉൾക്കൊള്ളുന്നു. റീഡയറക്‌ടുകൾ, കാഷെ ചെയ്‌ത പ്രതികരണങ്ങൾ, സെർവർ നിയമങ്ങൾ മാറ്റുന്നത്, ബ്രൗസർ വിപുലീകരണങ്ങൾ, ഒരു പ്രിഫ്ലൈറ്റിന് ശേഷമുള്ള യഥാർത്ഥ പ്രതികരണം എന്നിവയ്ക്ക് ഇപ്പോഴും ഫലം മാറ്റാനാകും.

    Cross-Origin Resource Sharing (CORS) നയം മനസ്സിലാക്കുക

    വെബ് ബ്രൗസറുകൾ സുരക്ഷ മുൻനിർത്തി നടപ്പിലാക്കുന്ന ഒരു സുപ്രധാന സംവിധാനമാണ് Cross-Origin Resource Sharing അഥവാ CORS. ഒരു വെബ് ആപ്ലിക്കേഷൻ അതിന്റെ സ്വന്തം ഡൊമെയ്നിൽ നിന്നല്ലാതെ മറ്റൊരു ഡൊമെയ്നിൽ (origin) നിന്ന് വിവരങ്ങൾ ശേഖരിക്കാൻ ശ്രമിക്കുമ്പോൾ ബ്രൗസർ ഈ സുരക്ഷാ നയം പരിശോധിക്കുന്നു. ഫ്രണ്ട്-എൻഡ് ഡെവലപ്പർമാർ, ബാക്ക്-എൻഡ് ഡെവലപ്പർമാർ, API പ്ലാറ്റ്‌ഫോം ഡെവലപ്പർമാർ, ഓപ്പറേഷൻസ് ഡെവലപ്പർമാർ എന്നിവർക്ക് തങ്ങളുടെ കോഡ് ബ്രൗസറിൽ കൃത്യമായി പ്രവർത്തിക്കുമോ എന്ന് മനസ്സിലാക്കാൻ CORS നയങ്ങളെക്കുറിച്ചുള്ള വ്യക്തമായ ധാരണ ആവശ്യമാണ്.

    ഒരു ബ്രൗസർ അഭ്യർത്ഥന അനുവദിക്കുമോ എന്ന് തീരുമാനിക്കുന്നത് സെർവർ നൽകുന്ന HTTP പ്രതികരണ തലക്കെട്ടുകളെ (response headers) അടിസ്ഥാനമാക്കിയാണ്. ഈ തലക്കെട്ടുകൾ കൃത്യമായി വിശകലനം ചെയ്യാൻ "CORS ചെക്കർ" സഹായിക്കുന്നു.

    CORS നയത്തിൽ Access-Control-Allow-Origin-ന്റെ പങ്ക്

    CORS നയത്തിന്റെ ഏറ്റവും പ്രധാനപ്പെട്ട ഭാഗമാണ് Access-Control-Allow-Origin എന്ന ഹെഡർ. ഒരു നിർദ്ദിഷ്ട ഉറവിടത്തിൽ നിന്നുള്ള അഭ്യർത്ഥനകൾക്ക് സെർവർ അനുമതി നൽകുന്നുണ്ടോ എന്ന് ബ്രൗസർ പരിശോധിക്കുന്നത് ഈ ഹെഡർ വഴിയാണ്.

    • കൃത്യമായ പൊരുത്തം: ഈ ഹെഡറിലെ മൂല്യം അഭ്യർത്ഥന നടത്തുന്ന ഉറവിടവുമായി കൃത്യമായി പൊരുത്തപ്പെടണം. ഉദാഹരണത്തിന്, https://app.example.com എന്ന ഉറവിടത്തിൽ നിന്നുള്ള അഭ്യർത്ഥനയ്ക്ക് ഇതേ മൂല്യം തന്നെ ഹെഡറിലും ഉണ്ടായിരിക്കണം.
    • വൈൽഡ്കാർഡ് (*) ഉപയോഗം: ക്രെഡൻഷ്യലുകൾ ഇല്ലാത്ത സാധാരണ അഭ്യർത്ഥനകൾക്ക് ഏത് ഉറവിടവും അനുവദിക്കുന്നതിനായി * ഉപയോഗിക്കാവുന്നതാണ്.
    • അസാധുവായ മൂല്യങ്ങൾ: Access-Control-Allow-Origin ഹെഡറിൽ ഒന്നിലധികം മൂല്യങ്ങൾ നൽകുകയോ കോമ ഉപയോഗിച്ച് വേർതിരിച്ച് നൽകുകയോ ചെയ്താൽ അത് അസാധുവായി കണക്കാക്കപ്പെടുന്നു.

    പ്രീഫ്ലൈറ്റ് (Preflight) അഭ്യർത്ഥനകളും അനുബന്ധ ഹെഡറുകളും

    ചില പ്രത്യേക HTTP അഭ്യർത്ഥനകൾ (ഉദാഹരണത്തിന്, സാധാരണ സുരക്ഷിതമല്ലാത്ത രീതികൾ അല്ലെങ്കിൽ പ്രത്യേക ഹെഡറുകൾ അടങ്ങിയവ) യഥാർത്ഥത്തിൽ അയക്കുന്നതിന് മുൻപ് ബ്രൗസർ ഒരു OPTIONS അഭ്യർത്ഥന അയക്കുന്നു. ഇതിനെയാണ് പ്രീഫ്ലൈറ്റ് അഭ്യർത്ഥന എന്ന് വിളിക്കുന്നത്. ഈ ഘട്ടത്തിൽ താഴെ പറയുന്ന ഹെഡറുകൾ നിർണായകമാണ്:

    1. Access-Control-Allow-Methods: പ്രീഫ്ലൈറ്റ് അഭ്യർത്ഥനയിൽ സെർവർ അനുവദിക്കുന്ന HTTP രീതികൾ (Methods) ഇതിൽ വ്യക്തമാക്കണം. GET, POST തുടങ്ങിയ CORS-സുരക്ഷിത രീതികൾ (CORS-safelisted methods) ഈ ഹെഡറിൽ പ്രത്യേകം കാണിക്കേണ്ടതില്ല.
    2. Access-Control-Allow-Headers: അഭ്യർത്ഥനയിൽ ഉൾപ്പെടുത്താൻ ഉദ്ദേശിക്കുന്ന തലക്കെട്ടുകൾക്ക് സെർവർ അനുമതി നൽകുന്നത് ഈ ഹെഡർ വഴിയാണ്.

    പ്രിഫ്ലൈറ്റ് പ്രതികരണങ്ങൾ പരിശോധിക്കുമ്പോൾ HTTP സ്റ്റാറ്റസ് കോഡ് വളരെ പ്രധാനമാണ്. പ്രിഫ്ലൈറ്റ് വിജയകരമാകാൻ പ്രതികരണത്തിന് 2xx സ്റ്റാറ്റസ് കോഡ് ഉണ്ടായിരിക്കണം. പ്രതികരണത്തിൽ HTTP സ്റ്റാറ്റസ് ലൈൻ ഇല്ലെങ്കിൽ, പ്രിഫ്ലൈറ്റ് പരിശോധനാ ഫലം അനിശ്ചിതത്വത്തിലാകും.

    ക്രെഡൻഷ്യലുകൾ ഉൾപ്പെടുത്തുമ്പോൾ ഉണ്ടാകുന്ന മാറ്റങ്ങൾ

    കുക്കികൾ (cookies) അല്ലെങ്കിൽ HTTP പ്രാമാണീകരണം (HTTP authentication) പോലുള്ള ക്രെഡൻഷ്യലുകൾ ഉൾപ്പെടുത്തി നടത്തുന്ന അഭ്യർത്ഥനകളിൽ CORS നിയമങ്ങൾ കൂടുതൽ കർശനമാകുന്നു.

    • Access-Control-Allow-Credentials: ക്രെഡൻഷ്യലുകൾ അടങ്ങിയ അഭ്യർത്ഥനകൾ അനുവദിക്കാൻ ഈ ഹെഡറിന്റെ മൂല്യം കൃത്യമായി true ആയിരിക്കണം.
    • വൈൽഡ്കാർഡ് നിയന്ത്രണം: ക്രെഡൻഷ്യലുകൾ ഉള്ളപ്പോൾ Access-Control-Allow-Origin ഹെഡറിൽ വൈൽഡ്കാർഡ് (*) ഉപയോഗിക്കാൻ പാടില്ല. കൂടാതെ, അനുവദനീയമായ രീതികൾക്കും ഹെഡറുകൾക്കുമുള്ള വൈൽഡ്കാർഡുകൾക്ക് അവയുടെ വൈൽഡ്കാർഡ് അർത്ഥം നഷ്ടപ്പെടുകയും ചെയ്യും.

    Authorization ഹെഡറിന്റെ പ്രത്യേകതകൾ

    CORS നയത്തിൽ Authorization ഹെഡറിന് പ്രത്യേക കൈകാര്യം ചെയ്യൽ ആവശ്യമാണ്. ക്രെഡൻഷ്യലുകൾ ഇല്ലാത്ത അഭ്യർത്ഥനകളിൽ മറ്റ് ഹെഡറുകൾക്കായി Access-Control-Allow-Headers: * ഉപയോഗിക്കാമെങ്കിലും, Authorization ഹെഡറിനെ ഇത് പിന്തുണയ്ക്കില്ല. Authorization ഹെഡർ ഉപയോഗിക്കണമെങ്കിൽ അത് Access-Control-Allow-Headers-ൽ വ്യക്തമായി തന്നെ രേഖപ്പെടുത്തിയിരിക്കണം.

    ഇൻപുട്ട് മാനദണ്ഡങ്ങളും പിശകുകളും

    "CORS ചെക്കർ" ടൂൾ ഉപയോഗിക്കുമ്പോൾ നൽകേണ്ട ഇൻപുട്ടുകളും അവയുടെ പരിധികളും താഴെ പറയുന്നവയാണ്:

    • HTTP പ്രതികരണ തലക്കെട്ടുകൾ: പരമാവധി 200,000 പ്രതീകങ്ങൾ വരെ ഒട്ടിക്കാം. ഇൻപുട്ട് ശൂന്യമാണെങ്കിൽ "പരിശോധിക്കുന്നതിന് മുമ്പ് HTTP പ്രതികരണ തലക്കെട്ടുകൾ ഒട്ടിക്കുക." എന്ന പിശക് കാണിക്കും. പരിധി കടന്നാൽ "ഈ പ്രതികരണം അസാധാരണമാംവിധം വലുതാണ്. ‹max› പ്രതീകങ്ങൾക്ക് കീഴിൽ ഇത് സൂക്ഷിക്കുക." എന്ന സന്ദേശം ലഭിക്കും. തെറ്റായ വരികൾക്ക് "ലൈൻ ‹line› ഒരു സാധുവായ HTTP ഹെഡറോ സ്റ്റാറ്റസ് ലൈനോ അല്ല." എന്നും, തെറ്റായ ഹെഡർ നാമങ്ങൾക്ക് "ലൈൻ ‹line›-ൽ ഒരു അസാധുവായ HTTP ഹെഡർ നാമം അടങ്ങിയിരിക്കുന്നു." എന്നും പിശക് കാണിക്കും.
    • അഭ്യർത്ഥന ഉത്ഭവം (Origin): സ്കീം, ഹോസ്റ്റ്, ഓപ്ഷണൽ പോർട്ട് എന്നിവ മാത്രമേ പാടുള്ളൂ (ഉദാഹരണത്തിന്: https://app.example.com). പാതയോ (path) ക്വറിയോ ഉൾപ്പെടുത്തിയാൽ "https://app.example.com പോലെയുള്ള ഒരു സ്കീം, ഹോസ്റ്റ്, ഓപ്ഷണൽ പോർട്ട് എന്നിവ ഉപയോഗിച്ച് മാത്രം ഒരു ഉത്ഭവം നൽകുക." എന്ന പിശക് വരും.
    • അഭ്യർത്ഥിച്ച രീതി (Method): സാധുവായ HTTP ടോക്കൺ ആയിരിക്കണം. തെറ്റായ രീതികൾക്ക് "സാധുവായ HTTP രീതി ടോക്കൺ നൽകുക." എന്നും, ബ്രൗസർ അനുവദിക്കാത്ത fetch രീതികൾക്ക് "ബ്രൗസറുകൾ fetch അഭ്യർത്ഥനകളിൽ ‹method› രീതി അനുവദിക്കുന്നില്ല." എന്നും കാണിക്കും.
    • അഭ്യർത്ഥിച്ച തലക്കെട്ട് പേരുകൾ: കോമകളോ പുതിയ വരികളോ ഉപയോഗിച്ച് വേർതിരിക്കണം. തെറ്റായ ഹെഡർ നാമങ്ങൾക്ക് "‹header› എന്നത് സാധുവായ HTTP അഭ്യർത്ഥന തലക്കെട്ട് നാമമല്ല." എന്ന പിശക് ലഭിക്കും.

    പൊതുവായ ഇൻപുട്ട് പ്രശ്നങ്ങൾക്ക് "ഹൈലൈറ്റ് ചെയ്‌ത ഇൻപുട്ട് പരിഹരിച്ച് വീണ്ടും ശ്രമിക്കുക." എന്ന സന്ദേശം കാണിക്കും.

    സ്വകാര്യതയും പ്രോസസ്സിംഗും

    ഈ ടൂൾ ഉപയോഗിക്കുമ്പോൾ നിങ്ങളുടെ ഡാറ്റയുടെ സുരക്ഷ പൂർണ്ണമായും ഉറപ്പാക്കപ്പെടുന്നു. നിങ്ങൾ നൽകുന്ന തലക്കെട്ടുകളും അഭ്യർത്ഥന വിശദാംശങ്ങളും നിങ്ങളുടെ ബ്രൗസറിൽ തന്നെ നിലനിൽക്കുന്നു. BroBroGo-ലേക്ക് യാതൊരുവിധ വിവരങ്ങളും അപ്‌ലോഡ് ചെയ്യുകയോ അവിടെ സംരക്ഷിക്കുകയോ ചെയ്യുന്നില്ല.

    പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ (FAQ)

    ഞാൻ യഥാർത്ഥ പ്രതികരണമോ പ്രിഫ്ലൈറ്റ് പ്രതികരണമോ ഒട്ടിക്കേണ്ടതുണ്ടോ?

    ബ്രൗസർ കോഡിന് ഒരു പ്രതികരണം വായിക്കാൻ കഴിയുമോ എന്ന് പരിശോധിക്കാൻ യഥാർത്ഥ പ്രതികരണം ഉപയോഗിക്കുക. OPTIONS മറുപടിക്കായി പ്രിഫ്ലൈറ്റ് പ്രതികരണം ഉപയോഗിക്കുക, അത് പിന്നീടുള്ള രീതിയും അതിൻ്റെ അഭ്യർത്ഥിച്ച തലക്കെട്ട് പേരുകളും അംഗീകരിക്കുന്നു.

    വൈൽഡ്കാർഡിന് ക്രെഡൻഷ്യലുകളിൽ പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്?

    കുക്കികൾ അല്ലെങ്കിൽ HTTP പ്രാമാണീകരണം ഉൾപ്പെടുത്തുമ്പോൾ, അനുവദനീയമായ ഉറവിടം അഭ്യർത്ഥിക്കുന്ന ഉറവിടവുമായി കൃത്യമായി പൊരുത്തപ്പെടണം. അനുവദനീയമായ രീതികൾക്കും ഹെഡറുകൾക്കുമുള്ള വൈൽഡ്കാർഡുകൾക്കും അവയുടെ വൈൽഡ്കാർഡ് അർത്ഥം നഷ്ടപ്പെടും.

    തത്സമയ അഭ്യർത്ഥന പ്രവർത്തിക്കുമെന്ന് പാസിംഗ് ഫലം തെളിയിക്കുന്നുണ്ടോ?

    ഇല്ല. ഈ ഫലം ഒട്ടിച്ച പ്രതികരണവും ഇവിടെ നൽകിയ അഭ്യർത്ഥന വിശദാംശങ്ങളും മാത്രം ഉൾക്കൊള്ളുന്നു. റീഡയറക്‌ടുകൾ, കാഷെ ചെയ്‌ത പ്രതികരണങ്ങൾ, സെർവർ നിയമങ്ങൾ മാറ്റുന്നത്, ബ്രൗസർ വിപുലീകരണങ്ങൾ, ഒരു പ്രിഫ്ലൈറ്റിന് ശേഷമുള്ള യഥാർത്ഥ പ്രതികരണം എന്നിവയ്ക്ക് ഇപ്പോഴും ഫലം മാറ്റാനാകും.

    ഈ ടൂൾ സെർവറുമായി ബന്ധപ്പെട്ട് പരിശോധന നടത്തുന്നുണ്ടോ?

    ഇല്ല, ഈ ടൂൾ നൽകിയിരിക്കുന്ന പ്രതികരണ തലക്കെട്ടുകളും അഭ്യർത്ഥന വിശദാംശങ്ങളും ബ്രൗസറിലെ CORS നിയമങ്ങളുമായി ഒത്തുനോക്കുക മാത്രമാണ് ചെയ്യുന്നത്. ഇത് സെർവറുമായി ബന്ധപ്പെടുകയോ, URL-കൾ വായിക്കുകയോ, കുക്കികൾ സജ്ജമാക്കുകയോ, DNS/TLS പരിശോധിക്കുകയോ, സെർവർ കോൺഫിഗറേഷനുകളിൽ മാറ്റം വരുത്തുകയോ ഇല്ല.