CORS ఎర్రర్‌లను ఎలా సరిచేయాలి (అవి ఎందుకు వస్తాయి)

CORS ఎర్రర్ అంటే మీ వెబ్ పేజీ వేరే origin (వేరే డొమైన్, పోర్ట్ లేదా ప్రోటోకాల్) నుండి response చదవడానికి ప్రయత్నించింది, కానీ ఆ సర్వర్ అలా చేయడానికి అనుమతించే హెడర్‌లు పంపలేదని అర్థం. వినియోగదారులను రక్షించడానికి బ్రౌజర్ ఆ response ను బ్లాక్ చేస్తుంది. దీన్ని సర్వర్‌లో మీ సైట్ origin కు Access-Control-Allow-Origin హెడర్ ఇవ్వడం ద్వారా, మరియు OPTIONS preflight requests ను హ్యాండిల్ చేయడం ద్వారా సరిచేస్తారు. లేదా మీ స్వంత backend ద్వారా అదే origin లో request పంపడం ద్వారా దీన్ని నివారించవచ్చు.

ఇది వెబ్ డెవలప్‌మెంట్‌లో అత్యంత గందరగోళం కలిగించే ఎర్రర్‌లలో ఒకటి, ఎందుకంటే request తరచూ సర్వర్‌కు సరిగ్గా చేరుతుంది. ఈ గైడ్ ఏమి జరుగుతోందో, మరియు ప్రతి రకాన్ని ఎలా సరిచేయాలో వివరిస్తుంది.

"origin" అంటే ఏమిటి

origin అంటే protocol, domain మరియు port కలయిక:

URL	Origin
`https://myapp.com/dashboard`	`https://myapp.com`
`https://api.myapp.com/users`	`https://api.myapp.com` (వేరే subdomain, కాబట్టి వేరే origin)
`http://localhost:5173`	`http://localhost:5173`
`http://localhost:3000`	`http://localhost:3000` (వేరే port, కాబట్టి వేరే origin)

బ్రౌజర్‌లు same-origin policy ను అనుసరిస్తాయి: పేజీపై ఉన్న JavaScript తన స్వంత origin నుండి responses ను స్వేచ్ఛగా చదవగలదు, కానీ ఇతరుల నుండి కాదు. CORS (Cross-Origin Resource Sharing) అనేది సర్వర్ ఈ అనుమతిని ఇవ్వడానికి ఉపయోగించే వ్యవస్థ: "ఈ origins నుండి వచ్చే పేజీలు నా responses ను చదవవచ్చు" అని సర్వర్ చెబుతుంది.

రెండు విషయాలు చాలా మందిని ఆశ్చర్యపరుస్తాయి:

Request తరచూ సర్వర్‌కు చేరుతుంది. CORS సాధారణంగా మీ కోడ్ response ను చదవడాన్ని ఆపుతుంది, సర్వర్ request అందుకోవడాన్ని కాదు. POST సేవ్ అయి ఉండవచ్చు, అయినా మీకు ఎర్రర్ కనిపించవచ్చు.
దీన్ని బ్రౌజర్‌లు మాత్రమే అమలు చేస్తాయి. curl, Postman మరియు సర్వర్ వైపు కోడ్ CORS ను పూర్తిగా పట్టించుకోవు. అందుకే "Postman లో పని చేస్తుంది" అంటే CORS గురించి ఏమీ చెప్పదు.

దశ 1: ఖచ్చితమైన ఎర్రర్ చదవండి

డెవలపర్ టూల్స్ తెరవండి (రైట్-క్లిక్ → Inspect), Console కు వెళ్లి పూర్తి మెసేజ్ చదవండి. Chrome మెసేజ్ ఏ సమస్య ఉందో చెబుతుంది:

మెసేజ్‌లో ఉన్నది	తప్పు ఏమిటి
`No 'Access-Control-Allow-Origin' header is present`	సర్వర్ ఆ హెడర్ అసలు పంపలేదు, లేదా request మీ CORS కోడ్ చేరకముందే విఫలమైంది (ఉదాహరణకు 404 లేదా 500)
`The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin`	సర్వర్ మీ 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`	సర్వర్ `Access-Control-Allow-Headers` లో ఆ హెడర్‌ను జాబితా చేయలేదు

ఆ తర్వాత Network ట్యాబ్ తెరిచి, విఫలమైన request ను (మరియు దానికంటే ముందు వచ్చిన OPTIONS request ను) కనుగొని, దాని status code మరియు response హెడర్‌లు చూడండి.

ముందుగా status code చూడండి. చాలా "CORS ఎర్రర్‌లు" నిజానికి దాగి ఉన్న సర్వర్ ఎర్రర్‌లే. సర్వర్ క్రాష్ అయితే లేదా 404 ఇస్తే, దాని ఎర్రర్ response లో తరచూ CORS హెడర్‌లు ఉండవు, కాబట్టి బ్రౌజర్ అసలు సమస్యకు బదులు CORS అని చూపిస్తుంది. 500 లేదా 404 ను సరిచేస్తే CORS ఎర్రర్ కూడా పోవచ్చు.

దశ 2: ఆ API ను బ్రౌజర్ నుండే పిలవాలా అని నిర్ణయించండి

హెడర్‌లు జోడించే ముందు అడగండి: బ్రౌజర్ ఈ API ను నేరుగా పిలవాలా?

Secret key అవసరమయ్యే మూడవ పక్ష API (OpenAI, Stripe secret key, చాలా ఇమెయిల్ సేవలు) బ్రౌజర్ నుండి ఎప్పుడూ పిలవకూడదు. ఆ key ప్రతి సందర్శకుడికీ కనిపిస్తుంది. బదులుగా మీ backend నుండి పిలవండి; సర్వర్-టు-సర్వర్ requests కు CORS వర్తించదు కాబట్టి సమస్య పోతుంది. API keys ను సురక్షితంగా ఎలా ఉంచాలో చూడండి.
మీరు నియంత్రించని మూడవ పక్ష API CORS హెడర్‌లు పంపకపోతే, దాన్ని మీ వైపు నుండి సరిచేయలేరు. మీ backend నుండి పిలవండి.
మీ స్వంత API ను సరిగ్గా కాన్ఫిగర్ చేయడం ద్వారా సరిచేయవచ్చు. కింద కొనసాగండి.

దశ 3: మీ సర్వర్‌లో సరిచేయండి

సర్వర్ తన responses కు సరైన హెడర్‌లు జోడించాలి, error responses తో సహా.

అసలు request కోసం పంపండి:

Access-Control-Allow-Origin: https://myapp.com (మీ ఫ్రంటెండ్ యొక్క ఖచ్చితమైన origin, చివర slash లేకుండా)
Vary: Origin, విలువ ఏ origin అడిగిందో బట్టి మారితే

preflight OPTIONS request కు విజయవంతమైన status (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 (మీరు పంపే ప్రతి custom హెడర్)
ఐచ్ఛికంగా Access-Control-Max-Age: 600, తద్వారా బ్రౌజర్ preflight ను కొంతసేపు కాష్ చేస్తుంది

చాలా frameworks కు ఇది చేసే package లేదా setting ఉంటుంది. Express లో cors package; FastAPI లో CORSMiddleware; ASP.NET Core లో AddCors; Spring లో @CrossOrigin లేదా CORS configuration. ఒక సాధారణ Express సెటప్:

import cors from "cors";

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

CORS హ్యాండ్లింగ్‌ను మీ routes మరియు authentication ముందు ఉంచండి, తద్వారా login లేని preflight requests 401 తో తిరస్కరించబడవు.

AI builder తో సెటప్‌ను ఖచ్చితంగా వివరించండి:

https://myapp.com వద్ద ఉన్న ఫ్రంటెండ్ https://api.myapp.com వద్ద ఉన్న API ను పిలుస్తోంది, మరియు "Response to preflight request doesn't pass access control check" ఎర్రర్ వస్తోంది. API పై CORS ను ఖచ్చితంగా https://myapp.com మరియు preview origin కు మాత్రమే అనుమతించేలా కాన్ఫిగర్ చేయండి, Content-Type మరియు Authorization హెడర్‌లతో GET, POST, PATCH, DELETE అనుమతించండి, auth కంటే ముందు OPTIONS ను హ్యాండిల్ చేయండి, మరియు error responses పై కూడా CORS హెడర్‌లు చేర్చండి.

దశ 4: కుకీలు మరియు credentials నిర్వహించండి

మీ ఫ్రంటెండ్ లాగిన్ session వంటి కుకీలను వేరే 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 requests చేయకపోవడమే. పేజీ ఉన్న అదే origin నుండి API ను అందించండి, ఉదాహరణకు https://myapp.com/api/... వద్ద:

అభివృద్ధిలో (development), చాలా dev servers proxy చేయగలవు. Vite యొక్క server.proxy సెట్టింగ్ /api ను వేరే పోర్ట్‌లోని మీ backend కు పంపగలదు, తద్వారా బ్రౌజర్ ఒకే origin తో మాత్రమే మాట్లాడుతుంది.
ప్రొడక్షన్‌లో, మీ హోస్ట్ rewrite లేదా proxy settings ద్వారా /api ను backend కు రూట్ చేయండి, లేదా frontend మరియు API ను ఒకే సర్వర్ నుండి అందించండి.

అప్పుడు ఫ్రంటెండ్ fetch("/api/orders") వంటి relative path ను పిలుస్తుంది. cross-origin request లేదు, origins మధ్య preflight లేదు, కుకీ సమస్యలు లేవు. preview మరియు ప్రొడక్షన్ కోసం API డొమైన్‌ను hard-code చేయాల్సిన అవసరం కూడా ఉండదు.

ఫ్రంటెండ్ backend ను పూర్తి URL కు బదులుగా relative /api paths తో పిలిచేలా మార్చండి, మరియు /api ను API సర్వర్‌కు ఫార్వర్డ్ చేసేలా dev proxy సెట్ చేయండి. తర్వాత ఇక అవసరం లేని CORS సెట్టింగ్‌లను తీసివేయండి.

వద్దు అని చేయకూడనివి

fetch లో mode: "no-cors". ఇది దేనినీ బైపాస్ చేయదు; మీ కోడ్‌కు ఖాళీ, చదవలేని response మాత్రమే ఇస్తుంది.
CORS ను నిలిపివేసే బ్రౌజర్ extensions. అవి మీ బ్రౌజర్‌ను మాత్రమే మారుస్తాయి. ప్రతి సందర్శకుడికీ ఎర్రర్ కనిపిస్తూనే ఉంటుంది.
నిజమైన యాప్‌ల కోసం పబ్లిక్ "CORS proxy" సేవలు. వాటి ద్వారా వెళ్లే ప్రతిదీ వారు చదవగలరు మరియు మార్చగలరు, మరియు అవి తరచూ పనిచేయవు.
లాగిన్ ఉన్న API పై Access-Control-Allow-Origin: *. ఇది credentials తో పనిచేయదు, మరియు ప్రైవేట్ డేటాకు తప్పు డిఫాల్ట్.
credentials అనుమతించి, ఏ Origin హెడర్ వచ్చినా దాన్ని తిరిగి పంపడం (reflect). దీనివల్ల ఏ వెబ్‌సైట్ అయినా మీ వినియోగదారుల తరపున లాగిన్ అయిన requests చేయగలదు. అనుమతి జాబితా (allowlist) వాడండి.

AI తో నిర్మించిన యాప్‌లలో సాధారణ కారణాలు

పరిస్థితి	పరిష్కారం
ఫ్రంటెండ్ secret key తో మూడవ పక్ష API ను పిలుస్తుంది	కాల్‌ను backend కు తరలించండి
Preview లో పని చేస్తుంది, ప్రచురించిన డొమైన్‌లో విఫలమవుతుంది	ప్రచురించిన మరియు custom-domain origins ను అనుమతి జాబితాలో చేర్చండి, లేదా relative `/api` paths వాడండి
కేవలం POST, PUT లేదా DELETE పై ఎర్రర్	Preflight హ్యాండిల్ కాలేదు; `OPTIONS` హ్యాండ్లింగ్ మరియు అనుమతించబడిన హెడర్‌లు జోడించండి
లాగిన్ జోడించిన తర్వాత ఎర్రర్ వచ్చింది	credentials కు ఖచ్చితమైన origin మరియు `Allow-Credentials` కావాలి
"CORS ఎర్రర్" కానీ Network ట్యాబ్‌లో 500 కనిపిస్తోంది	ముందు సర్వర్ ఎర్రర్ సరిచేయండి
API URL `localhost` కు hard-coded	relative paths లేదా per-environment setting వాడండి

Mythex లో CORS

Mythex ప్రాజెక్ట్‌లో వెబ్‌సైట్ మరియు API సర్వర్ ఉంటే, రెండూ ఒకే ప్రాజెక్ట్‌లో services గా నడుస్తాయి, మరియు మీరు preview లో వాటి మధ్య మారవచ్చు. ఫ్రంటెండ్ backend ను relative /api path ద్వారా పిలవాలని, dev లో proxy చేయాలని agent ను అడగడం చాలా CORS సమస్యలను నివారిస్తుంది. మీకు నిజంగా cross-origin calls అవసరమైతే, agent కు కన్సోల్ నుండి ఖచ్చితమైన ఎర్రర్ మరియు ఉన్న origins ఇవ్వండి. ప్రచురించిన యాప్‌లో కూడా ఫలితాన్ని తనిఖీ చేయండి, ఎందుకంటే దాని చిరునామా preview నుండి భిన్నంగా ఉంటుంది. డాక్స్‌లో Multi-service apps మరియు API backends చూడండి, మరియు మా గైడ్‌లు AI-నిర్మిత యాప్‌ను debug చేయడం మరియు frontend vs backend చదవండి.

CORS చెక్‌లిస్ట్

పూర్తి console ఎర్రర్ మరియు విఫలమైన request యొక్క status code చదివాను
దాగి ఉన్న 404 లేదా 500 లేదని నిర్ధారించుకున్నాను
Secret-key APIs ను బ్రౌజర్ నుండి కాకుండా backend నుండి పిలుస్తున్నాను
సర్వర్ ఖచ్చితమైన అనుమతించబడిన origins తో Access-Control-Allow-Origin పంపుతోంది
OPTIONS preflight అనుమతించిన methods మరియు headers తో, auth కంటే ముందు జవాబిస్తోంది
Error responses పై కూడా CORS హెడర్‌లు ఉన్నాయి
Credentials: ఖచ్చితమైన origin, Allow-Credentials: true, సరైన cookie settings
Preview, ప్రచురించిన మరియు custom-domain origins అన్నీ కవర్ అయ్యాయి, లేదా relative /api paths వాడబడుతున్నాయి
no-cors, పబ్లిక్ proxies, లేదా reflect-any-origin షార్ట్‌కట్‌లు లేవు

ప్రశ్నలు

CORS ఎర్రర్ అంటే ఏమిటి?

మీ పేజీ ఒక origin నుండి లోడ్ అయి, వేరే origin నుండి వచ్చిన response ను చదవడానికి ప్రయత్నించింది, కానీ ఆ సర్వర్ response లో అనుమతి హెడర్‌లు పంపలేదు. బ్రౌజర్ మీ కోడ్ ఆ response ను చదవకుండా ఆపుతుంది. పరిష్కారం ఫ్రంటెండ్ కోడ్‌లో కాదు, సర్వర్‌లో లేదా request ఎలా రూట్ అవుతుందో అక్కడ ఉంటుంది.

ఫ్రంటెండ్ నుండే CORS ఎర్రర్‌ను సరిచేయగలనా?

సరిగ్గా కాదు. mode: 'no-cors' వంటి సెట్టింగ్‌లు response ను మీ కోడ్‌కు కనిపించకుండా మాత్రమే చేస్తాయి. సర్వర్ సరైన Access-Control-Allow-Origin హెడర్ పంపేలా చేయాలి, లేదా API ను మీ స్వంత backend లేదా same-origin proxy ద్వారా పిలవాలి.

Access-Control-Allow-Origin: * సురక్షితమేనా?

ఎవరైనా చదవగలిగే పబ్లిక్ డేటాకు, అంటే లాగిన్ అవసరం లేని పబ్లిక్ API కి ఇది సరిపోతుంది. దీన్ని కుకీలు లేదా ఇతర credentials తో వాడలేరు. ప్రైవేట్ APIల కోసం అనుమతించబడిన ఖచ్చితమైన origins ను జాబితా చేయాలి.

Postman లేదా curl లో పని చేస్తుంది, బ్రౌజర్‌లో ఎందుకు కాదు?

CORS ను బ్రౌజర్‌లు మాత్రమే అమలు చేస్తాయి. Postman మరియు curl దీన్ని వర్తింపజేయవు, కాబట్టి అవి request ను విజయవంతం చేసినా, పేజీ JavaScript అదే request పంపినప్పుడు అది బ్లాక్ కావచ్చు.

preflight request అంటే ఏమిటి?

JSON POST లేదా Authorization హెడర్ ఉన్న request వంటి సాధారణం కాని requests కోసం, బ్రౌజర్ ముందుగా OPTIONS request పంపి ఏ methods మరియు headers అనుమతించబడ్డాయో సర్వర్‌ను అడుగుతుంది. ఆ OPTIONS request విఫలమైతే లేదా సరైన హెడర్‌లు లేకపోతే, అసలు request పంపబడదు.