CORS പിശകുകൾ എങ്ങനെ പരിഹരിക്കാം (അവ എന്തുകൊണ്ട് സംഭവിക്കുന്നു)

CORS പിശകിന്റെ അർത്ഥം, നിങ്ങളുടെ വെബ് പേജ് മറ്റൊരു origin-ൽ (മറ്റൊരു ഡൊമെയ്ൻ, പോർട്ട് അല്ലെങ്കിൽ പ്രോട്ടോക്കോൾ) നിന്ന് ഒരു response വായിക്കാൻ ശ്രമിച്ചു, ആ സെർവർ അത് അനുവദനീയമാണെന്ന് പറയുന്ന headers അയച്ചില്ല എന്നാണ്. ഉപയോക്താക്കളെ സംരക്ഷിക്കാൻ ബ്രൗസർ response തടയുന്നു. നിങ്ങൾ അത് സെർവറിൽ പരിഹരിക്കുന്നു: നിങ്ങളുടെ സൈറ്റിന്റെ origin-ന് Access-Control-Allow-Origin header തിരിച്ചു നൽകിയും OPTIONS preflight അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്തും. അല്ലെങ്കിൽ അതേ origin-ലുള്ള നിങ്ങളുടെ സ്വന്തം ബാക്ക് എൻഡ് വഴി അഭ്യർത്ഥന അയച്ച് അതിനെ ഒഴിവാക്കാം.

അഭ്യർത്ഥന സെർവറിൽ ശരിയായി എത്തുന്നതുകൊണ്ടാണ് ഇത് വളരെ ആശയക്കുഴപ്പമുണ്ടാക്കുന്ന പിശകുകളിൽ ഒന്ന്. എന്താണ് സംഭവിക്കുന്നത്, ഓരോ വകഭേദവും എങ്ങനെ പരിഹരിക്കാം എന്ന് ഈ ഗൈഡ് വിശദീകരിക്കുന്നു.

"origin" എന്നതിന്റെ അർത്ഥം

origin എന്നത് പ്രോട്ടോക്കോൾ, ഡൊമെയ്ൻ, പോർട്ട് എന്നിവയുടെ സംയോജനമാണ്:

URL	Origin
`https://myapp.com/dashboard`	`https://myapp.com`
`https://api.myapp.com/users`	`https://api.myapp.com` (വ്യത്യസ്ത സബ്ഡൊമെയ്ൻ, അതിനാൽ വ്യത്യസ്ത origin)
`http://localhost:5173`	`http://localhost:5173`
`http://localhost:3000`	`http://localhost:3000` (വ്യത്യസ്ത പോർട്ട്, അതിനാൽ വ്യത്യസ്ത origin)

ബ്രൗസറുകൾ same-origin policy പിന്തുടരുന്നു: ഒരു പേജിലെ JavaScript സ്വന്തം origin-ൽ നിന്നുള്ള responses സ്വതന്ത്രമായി വായിക്കാം, മറ്റുള്ളവയിൽ നിന്നുള്ളത് വായിക്കാനാകില്ല. CORS (Cross-Origin Resource Sharing) എന്നത് ഒരു സെർവറിന് സ്വമേധയാ അനുമതി നൽകുന്ന സംവിധാനമാണ്: "എന്റെ responses ഈ origins-ൽ നിന്നുള്ള പേജുകൾക്ക് വായിക്കാം."

രണ്ട് അനന്തരഫലങ്ങൾ ആളുകളെ അത്ഭുതപ്പെടുത്താറുണ്ട്:

അഭ്യർത്ഥന പലപ്പോഴും സെർവറിൽ എത്തുന്നു. CORS സാധാരണയായി തടയുന്നത് നിങ്ങളുടെ കോഡിന് response വായിക്കുന്നത് ആണ്, സെർവർ അഭ്യർത്ഥന സ്വീകരിക്കുന്നതല്ല. ഒരു POST സേവ് ചെയ്യപ്പെട്ടിരിക്കാം, നിങ്ങൾ പിശക് കണ്ടാലും.
ബ്രൗസറുകൾ മാത്രമേ ഇത് നടപ്പിലാക്കൂ. curl, Postman, സെർവർ-സൈഡ് കോഡ് എന്നിവ CORS പൂർണ്ണമായും അവഗണിക്കുന്നു. അതുകൊണ്ടാണ് "Postman-ൽ പ്രവർത്തിക്കുന്നു" എന്നത് CORS-നെക്കുറിച്ച് ഒന്നും പറയാത്തത്.

ഘട്ടം 1: കൃത്യമായ പിശക് വായിക്കുക

ഡെവലപ്പർ ടൂളുകൾ തുറക്കുക (വലത് ക്ലിക്ക് → Inspect), Console-ലേക്ക് പോകുക, മുഴുവൻ സന്ദേശവും വായിക്കുക. Chrome-ന്റെ വാചകം നിങ്ങൾക്ക് ഏത് പ്രശ്നമാണെന്ന് പറയുന്നു:

സന്ദേശത്തിൽ അടങ്ങിയിരിക്കുന്നത്	എന്താണ് തെറ്റ്
`No 'Access-Control-Allow-Origin' header is present`	സെർവർ header ഒട്ടും അയച്ചില്ല, അല്ലെങ്കിൽ അഭ്യർത്ഥന നിങ്ങളുടെ CORS കോഡിൽ എത്തുന്നതിന് മുൻപ് പരാജയപ്പെട്ടു (ഉദാഹരണത്തിന് 404 അല്ലെങ്കിൽ 500)
`The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin`	സെർവർ നിങ്ങളുടേതല്ലാത്ത ഒരു origin-ന് അനുമതി നൽകുന്നു
`Response to preflight request doesn't pass access control check`	`OPTIONS` preflight പരാജയപ്പെട്ടു
`...must not be the wildcard '*' when the request's credentials mode is 'include'`	നിങ്ങൾ കുക്കികൾ അയക്കുന്നു, സെർവർ `*` തിരിച്ചു നൽകി
`Request header field authorization is not allowed`	സെർവർ ആ header `Access-Control-Allow-Headers`-ൽ പട്ടികപ്പെടുത്തിയിട്ടില്ല

തുടർന്ന് Network ടാബ് തുറന്ന്, പരാജയപ്പെട്ട അഭ്യർത്ഥന (അതിന് മുൻപുള്ള ഏതെങ്കിലും OPTIONS അഭ്യർത്ഥനയും) കണ്ടെത്തി അതിന്റെ സ്റ്റാറ്റസ് കോഡും response headers-ഉം നോക്കുക.

ആദ്യം സ്റ്റാറ്റസ് കോഡ് പരിശോധിക്കുക. പല "CORS പിശകുകളും" യഥാർത്ഥത്തിൽ വേഷം മാറിയ സെർവർ പിശകുകളാണ്. സെർവർ crash ആയാലോ 404 നൽകിയാലോ, അതിന്റെ പിശക് response-ൽ പലപ്പോഴും CORS headers ഉണ്ടാകില്ല, അതിനാൽ ബ്രൗസർ യഥാർത്ഥ പ്രശ്നത്തിന് പകരം CORS എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. 500 അല്ലെങ്കിൽ 404 ശരിയാക്കുക, CORS പിശക് മാഞ്ഞേക്കാം.

ഘട്ടം 2: ആ API ബ്രൗസറിൽ നിന്ന് വിളിക്കണമോ എന്ന് തീരുമാനിക്കുക

Headers ചേർക്കുന്നതിന് മുൻപ് ചോദിക്കുക: ബ്രൗസർ ഈ API നേരിട്ട് വിളിക്കണോ?

Secret key ആവശ്യമുള്ള മൂന്നാം-കക്ഷി API (OpenAI, Stripe secret key, മിക്ക ഇമെയിൽ സേവനങ്ങളും) ഒരിക്കലും ബ്രൗസറിൽ നിന്ന് വിളിക്കരുത്. Key എല്ലാ സന്ദർശകർക്കും കാണാനാകും. പകരം നിങ്ങളുടെ ബാക്ക് എൻഡിൽ നിന്ന് വിളിക്കുക, അപ്പോൾ CORS പ്രശ്നം മാഞ്ഞുപോകും, കാരണം സെർവർ-ടു-സെർവർ അഭ്യർത്ഥനകൾ CORS-ന് വിധേയമല്ല. API keys എങ്ങനെ സുരക്ഷിതമായി സൂക്ഷിക്കാം കാണുക.
നിങ്ങൾ നിയന്ത്രിക്കാത്ത മൂന്നാം-കക്ഷി API CORS headers അയക്കുന്നില്ലെങ്കിൽ, നിങ്ങളുടെ ഭാഗത്തുനിന്ന് അത് പരിഹരിക്കാനാകില്ല. നിങ്ങളുടെ ബാക്ക് എൻഡിൽ നിന്ന് വിളിക്കുക.
നിങ്ങളുടെ സ്വന്തം API ശരിയായി കോൺഫിഗർ ചെയ്ത് പരിഹരിക്കാം. താഴെ തുടരുക.

ഘട്ടം 3: സെർവറിൽ പരിഹരിക്കുക

സെർവർ പിശക് response-കൾ ഉൾപ്പെടെ എല്ലാ responses-ലും ശരിയായ headers ചേർക്കണം.

യഥാർത്ഥ അഭ്യർത്ഥനയ്ക്ക് ഇത് അയക്കുക:

Access-Control-Allow-Origin: https://myapp.com (നിങ്ങളുടെ ഫ്രണ്ട് എൻഡിന്റെ കൃത്യമായ origin, അവസാനം slash ഇല്ലാതെ)
Vary: Origin, മൂല്യം ചോദിച്ച origin-നെ ആശ്രയിച്ചിരിക്കുന്നെങ്കിൽ

OPTIONS preflight അഭ്യർത്ഥനയ്ക്ക് വിജയ സ്റ്റാറ്റസ് (200 അല്ലെങ്കിൽ 204) നൽകുക, ഒപ്പം:

Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization (നിങ്ങൾ അയക്കുന്ന ഓരോ കസ്റ്റം header-ഉം)
ഓപ്ഷണലായി Access-Control-Max-Age: 600, അതിലൂടെ ബ്രൗസർ preflight കുറച്ചുനേരം cache ചെയ്യും

മിക്ക ഫ്രെയിംവർക്കുകൾക്കും ഇത് ചെയ്യുന്ന ഒരു പാക്കേജോ സെറ്റിംഗോ ഉണ്ട്. Express-ൽ cors പാക്കേജ്; FastAPI-ൽ CORSMiddleware; ASP.NET Core-ൽ AddCors; Spring-ൽ @CrossOrigin അല്ലെങ്കിൽ CORS കോൺഫിഗറേഷൻ. ഒരു സാധാരണ Express സെറ്റപ്പ്:

import cors from "cors";

app.use(cors({
  origin: ["https://myapp.com", "http://localhost:5173"],
  credentials: true,
}));

CORS കൈകാര്യം ചെയ്യുന്നത് നിങ്ങളുടെ routes-നും authentication-നും മുൻപ് വയ്ക്കുക, അങ്ങനെ ലോഗിൻ ഇല്ലാത്ത preflight അഭ്യർത്ഥനകൾ 401 കൊണ്ട് നിരസിക്കപ്പെടില്ല.

ഒരു AI ബിൽഡറിനൊപ്പം, സെറ്റപ്പ് കൃത്യമായി വിവരിക്കുക:

https://myapp.com-ലെ ഫ്രണ്ട് എൻഡ് https://api.myapp.com-ലെ API വിളിക്കുന്നു, "Response to preflight request doesn't pass access control check" ലഭിക്കുന്നു. API-യിൽ CORS കോൺഫിഗർ ചെയ്യുക: കൃത്യമായി https://myapp.com-ഉം പ്രിവ്യൂ origin-ഉം അനുവദിക്കുക, Content-Type, Authorization headers-ഓടെ GET, POST, PATCH, DELETE അനുവദിക്കുക, OPTIONS-നെ auth-ന് മുൻപ് കൈകാര്യം ചെയ്യുക, പിശക് responses-ലും CORS headers ഉൾപ്പെടുത്തുക.

ഘട്ടം 4: കുക്കികളും credentials-ഉം കൈകാര്യം ചെയ്യുക

ഫ്രണ്ട് എൻഡ് മറ്റൊരു origin-ലേക്ക് കുക്കികൾ (ഉദാഹരണത്തിന് ലോഗിൻ സെഷൻ) അയക്കുന്നെങ്കിൽ, ഇരുവശവും ഒത്തുപോകണം:

ഫ്രണ്ട് എൻഡ് fetch-ൽ credentials: "include" സജ്ജമാക്കുന്നു, അല്ലെങ്കിൽ axios-ൽ withCredentials: true.
സെർവർ Access-Control-Allow-Credentials: true അയക്കുന്നു.
സെർവറിന്റെ Access-Control-Allow-Origin കൃത്യമായ origin ആയിരിക്കണം, * അല്ല.

ക്രോസ്-സൈറ്റ് കുക്കികൾക്ക് കുക്കിയിൽ SameSite=None; Secure വേണം, ചില ബ്രൗസറുകൾ മൂന്നാം-കക്ഷി കുക്കികളെ കൂടുതൽ നിയന്ത്രിക്കുന്നു. ഘട്ടം 5-ലെ സമീപനം തിരഞ്ഞെടുക്കാൻ അതൊരു കാരണം കൂടിയാണ്.

ഘട്ടം 5: same-origin സെറ്റപ്പിലൂടെ CORS ഒഴിവാക്കുക

പലപ്പോഴും ഏറ്റവും വൃത്തിയുള്ള പരിഹാരം ഒരു cross-origin അഭ്യർത്ഥനയും നടത്താതിരിക്കലാണ്. API-യെ പേജിന്റെ അതേ origin-ൽ സേവനം ചെയ്യുക, ഉദാഹരണത്തിന് https://myapp.com/api/...:

ഡെവലപ്മെന്റിൽ, മിക്ക ഡെവ് സെർവറുകൾക്കും proxy ചെയ്യാനാകും. Vite-ന്റെ server.proxy സെറ്റിംഗ് /api മറ്റൊരു പോർട്ടിലെ ബാക്ക് എൻഡിലേക്ക് അയക്കാം, അതിനാൽ ബ്രൗസർ ഒരൊറ്റ origin-നോടു മാത്രമേ സംസാരിക്കൂ.
ഉൽപ്പാദനത്തിൽ, /api ബാക്ക് എൻഡിലേക്ക് നിങ്ങളുടെ ഹോസ്റ്റിന്റെ rewrite അല്ലെങ്കിൽ proxy സെറ്റിംഗ്സ് വഴി റൂട്ട് ചെയ്യുക, അല്ലെങ്കിൽ ഫ്രണ്ട് എൻഡും API-യും ഒരേ സെർവറിൽ നിന്ന് സേവനം ചെയ്യുക.

അതിനുശേഷം ഫ്രണ്ട് എൻഡ് fetch("/api/orders") പോലുള്ള relative പാത വിളിക്കുന്നു. Cross-origin അഭ്യർത്ഥനയില്ല, origins-ന് കുറുകെയുള്ള preflight ഇല്ല, കുക്കി പ്രശ്നങ്ങളുമില്ല. പ്രിവ്യൂവും ഉൽപ്പാദനവും തമ്മിൽ വ്യത്യാസപ്പെടുന്ന ഒരു API ഡൊമെയ്ൻ നിങ്ങൾ hard-code ചെയ്യേണ്ടതുമില്ല.

ഫ്രണ്ട് എൻഡ് ബാക്ക് എൻഡിനെ മുഴുവൻ URL-ന് പകരം relative /api പാതകൾ വഴി വിളിക്കുക, /api API സെർവറിലേക്ക് അയക്കുന്ന ഒരു dev proxy സജ്ജമാക്കുക. പിന്നെ ഇനി ആവശ്യമില്ലാത്ത CORS സെറ്റിംഗ്സ് നീക്കം ചെയ്യുക.

ചെയ്യാൻ പാടില്ലാത്തത്

fetch-ൽ mode: "no-cors". അത് ഒന്നും മറികടക്കുന്നില്ല; നിങ്ങളുടെ കോഡിന് ശൂന്യവും വായിക്കാനാകാത്തതുമായ ഒരു response നൽകുന്നു.
CORS റദ്ദാക്കുന്ന ബ്രൗസർ എക്സ്റ്റൻഷനുകൾ. അവ നിങ്ങളുടെ ബ്രൗസറിനെ മാത്രമേ മാറ്റുന്നുള്ളൂ. എല്ലാ സന്ദർശകരും ഇപ്പോഴും പിശക് കാണും.
യഥാർത്ഥ ആപ്പുകൾക്ക് പൊതു "CORS proxy" സേവനങ്ങൾ. അവയിലൂടെ കടന്നുപോകുന്ന എല്ലാം അവർക്ക് വായിക്കാനും മാറ്റാനും കഴിയും, അവ പലപ്പോഴും പ്രവർത്തനരഹിതമാകും.
ലോഗിനുള്ള API-യിൽ Access-Control-Allow-Origin: *. Credentials ഉപയോഗിച്ച് അത് പ്രവർത്തിക്കില്ല, സ്വകാര്യ ഡാറ്റയ്ക്ക് തെറ്റായ സ്ഥിരസ്ഥിതിയുമാണ്.
ഏത് Origin header-ഉം തിരിച്ചു പ്രതിഫലിപ്പിക്കുന്നത് credentials അനുവദിച്ചുകൊണ്ട്. അത് ഏത് വെബ്സൈറ്റിനും നിങ്ങളുടെ ഉപയോക്താക്കളുടെ പേരിൽ ലോഗിൻ ചെയ്ത അഭ്യർത്ഥനകൾ നടത്താൻ അനുവദിക്കുന്നു. Allowlist ഉപയോഗിക്കുക.

AI നിർമ്മിച്ച ആപ്പുകളിലെ സാധാരണ കാരണങ്ങൾ

സാഹചര്യം	പരിഹാരം
ഫ്രണ്ട് എൻഡ് secret key ഉള്ള മൂന്നാം-കക്ഷി API വിളിക്കുന്നു	വിളി ബാക്ക് എൻഡിലേക്ക് മാറ്റുക
പ്രിവ്യൂവിൽ പ്രവർത്തിക്കുന്നു, പ്രസിദ്ധീകരിച്ച ഡൊമെയ്‌നിൽ പരാജയപ്പെടുന്നു	പ്രസിദ്ധീകരിച്ചതും കസ്റ്റം-ഡൊമെയ്ൻ origins-ഉം allowlist-ൽ ചേർക്കുക, അല്ലെങ്കിൽ relative `/api` പാതകൾ ഉപയോഗിക്കുക
POST, PUT അല്ലെങ്കിൽ DELETE-ൽ മാത്രം പിശക്	Preflight കൈകാര്യം ചെയ്തിട്ടില്ല; `OPTIONS` കൈകാര്യം ചെയ്യലും അനുവദനീയമായ headers-ഉം ചേർക്കുക
ലോഗിൻ ചേർത്ത ശേഷം പിശക് വന്നു	Credentials-ന് കൃത്യമായ origin-ഉം `Allow-Credentials`-ഉം വേണം
"CORS പിശക്" എന്നാൽ Network ടാബിൽ 500	ആദ്യം സെർവർ പിശക് പരിഹരിക്കുക
API URL `localhost`-ൽ hard-code ചെയ്തിരിക്കുന്നു	relative പാതകളോ ഓരോ എൻവയോൺമെന്റിനുമുള്ള സെറ്റിംഗോ ഉപയോഗിക്കുക

Mythex-ലെ CORS

ഒരു Mythex പ്രോജക്റ്റിന് ഒരു വെബ്സൈറ്റും ഒരു API സെർവറും ഉള്ളപ്പോൾ, രണ്ടും ഒരേ പ്രോജക്റ്റിൽ സേവനങ്ങളായി പ്രവർത്തിക്കുന്നു, പ്രിവ്യൂവിൽ അവയ്ക്കിടയിൽ മാറാനാകും. ഫ്രണ്ട് എൻഡ് ബാക്ക് എൻഡിനെ relative /api പാതയിലൂടെ വിളിക്കാൻ ഏജന്റിനോട് ആവശ്യപ്പെടുന്നത് (ഡെവലപ്മെന്റിൽ proxy ചെയ്യുന്നത്) മിക്ക CORS പ്രശ്നങ്ങളും ഒഴിവാക്കും. Cross-origin വിളികൾ നിർബന്ധമാണെങ്കിൽ, കൺസോളിലെ കൃത്യമായ പിശകും ഉൾപ്പെട്ട origins-ഉം ഏജന്റിന് നൽകുക. പ്രസിദ്ധീകരിച്ച ആപ്പിന്റെ വിലാസം പ്രിവ്യൂവിൽ നിന്ന് വ്യത്യസ്തമായതിനാൽ, ഫലം പ്രസിദ്ധീകരിച്ച ആപ്പിലും പരിശോധിക്കുക. ഡോക്സിലെ Multi-service apps, API backends എന്നിവയും, ഞങ്ങളുടെ AI നിർമ്മിച്ച ആപ്പ് ഡീബഗ് ചെയ്യുന്നത്, ഫ്രണ്ട് എൻഡും ബാക്ക് എൻഡും ഗൈഡുകളും കാണുക.

CORS ചെക്ക്‌ലിസ്റ്റ്

മുഴുവൻ കൺസോൾ പിശകും പരാജയപ്പെട്ട അഭ്യർത്ഥനയുടെ സ്റ്റാറ്റസ് കോഡും വായിച്ചു
മറഞ്ഞിരിക്കുന്ന 404 അല്ലെങ്കിൽ 500 ഒഴിവാക്കി
Secret-key API-കൾ ബ്രൗസറിൽ നിന്നല്ല, ബാക്ക് എൻഡിൽ നിന്നാണ് വിളിക്കുന്നത്
സെർവർ കൃത്യമായ അനുവദനീയ origins-ഓടെ Access-Control-Allow-Origin അയക്കുന്നു
OPTIONS preflight അനുവദനീയമായ methods-ഉം headers-ഉം ഉപയോഗിച്ച് auth-ന് മുൻപ് മറുപടി നൽകുന്നു
പിശക് responses-ലും CORS headers ഉണ്ട്
Credentials: കൃത്യമായ origin, Allow-Credentials: true, ശരിയായ cookie സെറ്റിംഗ്സ്
പ്രിവ്യൂ, പ്രസിദ്ധീകരിച്ചതും കസ്റ്റം-ഡൊമെയ്ൻ origins-ഉം എല്ലാം ഉൾപ്പെടുന്നു, അല്ലെങ്കിൽ relative /api പാതകൾ ഉപയോഗിക്കുന്നു
no-cors, പൊതു proxy-കൾ, reflect-any-origin കുറുക്കുവഴികൾ ഇല്ല

ചോദ്യങ്ങൾ

CORS പിശകിന്റെ അർത്ഥം എന്ത്?

ഒരു origin-ൽ നിന്ന് ലോഡ് ചെയ്ത നിങ്ങളുടെ പേജ്, മറ്റൊരു origin-ൽ നിന്നുള്ള ഒരു response വായിക്കാൻ ശ്രമിച്ചു, ആ സെർവറിന്റെ response അത് അനുവദിക്കുന്ന headers ഉൾക്കൊള്ളുന്നില്ല. ബ്രൗസർ response നിങ്ങളുടെ കോഡിന് വായിക്കുന്നത് തടയുന്നു. പരിഹാരം സെർവറിലോ അഭ്യർത്ഥന റൂട്ട് ചെയ്യുന്ന രീതിയിലോ ആണ്, ഫ്രണ്ട് എൻഡ് കോഡിലല്ല.

ഫ്രണ്ട് എൻഡിൽ നിന്ന് CORS പിശക് പരിഹരിക്കാനാകുമോ?

ശരിയായ രീതിയിൽ ഇല്ല. `mode: 'no-cors'` പോലുള്ള സെറ്റിംഗ്സ് response നിങ്ങളുടെ കോഡിൽ നിന്ന് മറയ്ക്കുക മാത്രമേ ചെയ്യൂ. സെർവർ ശരിയായ `Access-Control-Allow-Origin` header അയക്കുന്നതിലൂടെയോ, നിങ്ങളുടെ സ്വന്തം ബാക്ക് എൻഡ് അല്ലെങ്കിൽ same-origin proxy വഴി API വിളിക്കുന്നതിലൂടെയോ ആണ് ഇത് പരിഹരിക്കുന്നത്.

`Access-Control-Allow-Origin: *` സുരക്ഷിതമാണോ?

ആർക്കും വായിക്കാവുന്ന പൊതു ഡാറ്റയ്ക്ക് ഇത് ശരിയാണ്, ഉദാഹരണത്തിന് ലോഗിൻ ഇല്ലാത്ത പൊതു API. കുക്കികളോടോ മറ്റ് credentials-ഓടോ ഇത് ഉപയോഗിക്കാനാകില്ല, സ്വകാര്യ API-കൾക്ക് അനുവദനീയമായ origins കൃത്യമായി പട്ടികപ്പെടുത്തണം.

എന്തുകൊണ്ട് എന്റെ അഭ്യർത്ഥന Postman അല്ലെങ്കിൽ curl-ൽ പ്രവർത്തിക്കുന്നു, പക്ഷേ ബ്രൗസറിൽ പ്രവർത്തിക്കുന്നില്ല?

CORS നടപ്പിലാക്കുന്നത് ബ്രൗസറുകൾ മാത്രമാണ്. Postman, curl പോലുള്ള ടൂളുകൾ അത് ബാധകമാക്കുന്നില്ല, അതിനാൽ പേജിന്റെ JavaScript അഭ്യർത്ഥന നടത്തുമ്പോൾ അത് അവിടെ വിജയിച്ചാലും തടയപ്പെടാം.

എന്താണ് preflight അഭ്യർത്ഥന?

JSON POST പോലുള്ള ലളിതമല്ലാത്ത അഭ്യർത്ഥനകൾക്ക്, അല്ലെങ്കിൽ Authorization header ഉള്ളവയ്ക്ക്, ബ്രൗസർ ആദ്യം ഏത് methods-ഉം headers-ഉം അനുവദനീയമെന്ന് സെർവറിനോട് ചോദിച്ചുകൊണ്ട് ഒരു OPTIONS അഭ്യർത്ഥന അയക്കുന്നു. ആ OPTIONS അഭ്യർത്ഥന പരാജയപ്പെടുകയോ ശരിയായ headers ഇല്ലാതിരിക്കുകയോ ചെയ്താൽ യഥാർത്ഥ അഭ്യർത്ഥന ഒരിക്കലും അയക്കപ്പെടില്ല.