CORS error များ ပြင်နည်း (ဘာကြောင့် ဖြစ်သလဲ)

CORS error ဆိုသည်မှာ သင့် web page က အခြား origin (အခြား domain၊ port သို့မဟုတ် protocol) မှ response ကို ဖတ်ရန် ကြိုးစားခဲ့သော်လည်း ထို server က ခွင့်ပြုကြောင်း header များ မပို့ခဲ့ခြင်း ဖြစ်သည်။ Browser က အသုံးပြုသူကို ကာကွယ်ရန် response ကို ပိတ်ဆို့သည်။ ပြင်ရန်မှာ server ပေါ်တွင် ဖြစ်သည်: သင့် site ၏ origin အတွက် Access-Control-Allow-Origin header ပြန်ပေးပြီး OPTIONS preflight request များကို ကိုင်တွယ်ပါ၊ သို့မဟုတ် သင့် ကိုယ်ပိုင် backend ကနေ same origin ဖြင့် request ကို ပို့ခြင်းဖြင့် ရှောင်ပါ။

ဤအမှားသည် web development တွင် အလွန် ရှုပ်ထွေးသော အမှားတစ်ခု ဖြစ်သည်၊ အကြောင်းမှာ request သည် မကြာခဏ server ထံ အောင်မြင်စွာ ရောက်သော်လည်း ဖြစ်သည်။ ဤလမ်းညွှန်သည် ဘာဖြစ်နေသလဲ နှင့် variant တစ်ခုစီကို ဘယ်လိုပြင်မလဲ ရှင်းပြသည်။

"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 ကွဲ)

Browser များသည် same-origin policy ကို လိုက်နာသည်: စာမျက်နှာ၏ JavaScript သည် ကိုယ့် origin မှ response များကို လွတ်လပ်စွာ ဖတ်နိုင်သော်လည်း အခြားမှ ဖတ်၍ မရပါ။ CORS (Cross-Origin Resource Sharing) ဆိုသည်မှာ server က ဝင်ရောက်ခွင့် ပေးသည့်စနစ်ဖြစ်သည်: "ဤ origin များမှ စာမျက်နှာများက ကျွန်ုပ်၏ response များကို ဖတ်ခွင့်ရှိသည်" ဟု ကြေညာခြင်း။

လူအများစု အံ့သြတတ်သော အချက်နှစ်ခု:

Request သည် မကြာခဏ server ထံ ရောက်သည်။ CORS က များသောအားဖြင့် သင့် code ကို response ဖတ်ခြင်း ကို ပိတ်ဆို့သည်၊ server ကို request ရယူခြင်းကို မဟုတ်ပါ။ POST တစ်ခု သိမ်းဆည်းခံရနိုင်ပေမဲ့ error တစ်ခု မြင်ရနိုင်သည်။
CORS ကို browser များက သာ ပြဌာန်းသည်။ curl၊ Postman နှင့် server-side code များက CORS ကို လုံးဝ လျစ်လျူရှုသည်။ ထို့ကြောင့် "Postman တွင် အလုပ်လုပ်သည်" ဆိုခြင်းသည် CORS အကြောင်း ဘာမျှ မပြောပါ။

အဆင့် ၁: တိကျသော error ကို ဖတ်ပါ

Developer tools (right-click → Inspect) ကို ဖွင့်ပြီး Console သို့သွားကာ မက်ဆေ့ချ် အပြည့်အစုံကို ဖတ်ပါ။ Chrome ၏ စာသားက ဘယ်ပြဿနာ ရှိသလဲ ပြောပြသည်:

မက်ဆေ့ချ်တွင် ပါသော စာသား	ဘာမှားနေသလဲ
`No 'Access-Control-Allow-Origin' header is present`	Server က header လုံးဝ မပို့ခဲ့၊ သို့မဟုတ် request သည် CORS code ကို မရောက်မီ ပျက်ခဲ့ (ဥပမာ 404 သို့မဟုတ် 500)
`The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin`	Server က သင့် 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'`	Cookie ပို့နေပြီး server က `*` ပြန်ခဲ့
`Request header field authorization is not allowed`	Server က `Access-Control-Allow-Headers` တွင် ထို header ကို မစာရင်းသွင်းထား

ထို့နောက် Network tab ကို ဖွင့်ပြီး မအောင်မြင်သော request (နှင့် ရှေ့မှ OPTIONS request များ) ကို ရှာကာ status code နှင့် response header များကို ကြည့်ပါ။

Status code ကို ဦးစွာ စစ်ပါ။ "CORS error" အများအပြားမှာ တကယ်တော့ server error ဝှက်ဖုံးထားခြင်း ဖြစ်သည်။ Server crash ဖြစ်ခြင်း သို့မဟုတ် 404 ပြန်ခြင်းဖြစ်လျှင် error response တွင် CORS header များ မပါတတ်ပါ၊ ထို့ကြောင့် browser က အမှန်ပြဿနာ အစား CORS ဟု ပြသည်။ 500 သို့မဟုတ် 404 ကို ပြင်လိုက်လျှင် CORS error ပျောက်သွားနိုင်သည်။

အဆင့် ၂: ထို API ကို browser မှ တိုက်ရိုက် ခေါ်သင့်/မသင့် ဆုံးဖြတ်ပါ

Header များ ထည့်မီ မေးပါ: browser က ဤ API ကို တိုက်ရိုက် ခေါ်သင့်ပါသလား?

Secret key လိုအပ်သော third-party API (OpenAI၊ Stripe secret key၊ email service အများစု) ကို browser မှ ဘယ်တော့မှ မခေါ်သင့်ပါ။ Key ကို ဝင်ရောက်ကြည့်သူ အားလုံး မြင်နိုင်မည်။ သင့် backend မှ ခေါ်ပါ၊ ထိုအခါ CORS ပြဿနာ ပျောက်သွားမည်၊ အကြောင်းမှာ server-to-server request များသည် CORS ၏ အကျုံးဝင်ခြင်း မရှိသောကြောင့်ဖြစ်သည်။ API key များကို ဘေးကင်းစွာ ထိန်းသိမ်းနည်း ကို ကြည့်ပါ။
သင် ထိန်းချုပ်မှု မရှိသော third-party API သည် CORS header မပို့ပါက သင့်ဘက်မှ ပြင်၍ မရပါ။ သင့် backend မှ ခေါ်ပါ။
သင့်ကိုယ်ပိုင် API ကို မှန်ကန်စွာ configure လုပ်ခြင်းဖြင့် ပြင်နိုင်သည်။ အောက်တွင် ဆက်ကြည့်ပါ။

အဆင့် ၃: သင့် server ပေါ်တွင် ပြင်ပါ

Server သည် error response များအပါအဝင် သင့်တော်သော header များကို ထည့်ရမည်။

Request အစစ်အတွက် ပို့ရမည်:

Access-Control-Allow-Origin: https://myapp.com (သင့် frontend ၏ 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 header တိုင်း)
ရွေးချယ်စရာ Access-Control-Max-Age: 600၊ preflight ကို အချိန်အတော်ကြာ browser က cache လုပ်စေရန်

Framework အများစုတွင် ဤအရာကို လုပ်ပေးသော package သို့မဟုတ် setting ရှိသည်။ Express တွင် cors package၊ FastAPI တွင် CORSMiddleware၊ ASP.NET Core တွင် AddCors၊ Spring တွင် @CrossOrigin သို့မဟုတ် CORS configuration။ Express setup ရိုးရိုးတစ်ခု:

import cors from "cors";

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

CORS ကိုင်တွယ်မှုကို route များနှင့် authentication မတိုင်မီ ထားပါ၊ preflight request များ (login မပါ) သည် 401 ဖြင့် ပယ်ချခံရခြင်း မရှိစေရန်။

AI builder တွင် ပြင်ဆင်ချက်ကို တိကျစွာ ဖော်ပြပါ:

https://myapp.com ရှိ frontend သည် https://api.myapp.com ရှိ API ကို ခေါ်ပြီး "Response to preflight request doesn't pass access control check" ရနေသည်။ API တွင် CORS ကို https://myapp.com နှင့် preview origin ကိုသာ ခွင့်ပြုရန် configure လုပ်ပါ၊ GET၊ POST၊ PATCH၊ DELETE ကို Content-Type နှင့် Authorization header များဖြင့် ခွင့်ပြုပါ၊ OPTIONS ကို auth မတိုင်မီ ကိုင်တွယ်ပါ၊ error response များတွင်လည်း CORS header များ ပါစေပါ။

Frontend သည် အခြား origin သို့ cookie (ဥပမာ login session) ပို့လျှင် နှစ်ဘက်လုံး သဘောတူရမည်:

Frontend က fetch တွင် credentials: "include" ကို သတ်မှတ်ပါ၊ သို့မဟုတ် axios တွင် withCredentials: true။
Server က Access-Control-Allow-Credentials: true ပို့ရမည်။
Server ၏ Access-Control-Allow-Origin သည် origin အတိအကျ ဖြစ်ရမည်၊ * မဟုတ်ပါ။

Site ကြား cookie များသည် cookie တွင် SameSite=None; Secure လိုအပ်ပြီး browser အချို့က third-party cookie များကို ထပ်ကန့်သတ်သည်။ ထိုကြောင့် အဆင့် ၅ ၏ နည်းလမ်းကို ဦးစားပေးခြင်း ဖြစ်သည်။

အဆင့် ၅: Same-origin setup ဖြင့် CORS ကို ရှောင်ပါ

မကြာခဏ အသန့်ဆုံး ပြင်နည်းမှာ cross-origin request များ လုံးဝ မလုပ်ခြင်း ဖြစ်သည်။ API ကို စာမျက်နှာနှင့် တူညီသော origin မှ ဝန်ဆောင်ပါ၊ ဥပမာ https://myapp.com/api/...:

Development တွင် dev server အများစုက proxy လုပ်နိုင်သည်။ Vite ၏ server.proxy setting က /api ကို အခြား port ရှိ backend သို့ ပို့နိုင်ပြီး browser က origin တစ်ခုတည်းသာ ဆက်သွယ်သည်။
Production တွင် /api ကို host ၏ rewrite သို့မဟုတ် proxy setting များမှတစ်ဆင့် backend သို့ ပို့ပါ၊ ဒါမှမဟုတ် frontend နှင့် API ကို server တစ်ခုတည်းမှ ဝန်ဆောင်ပါ။

ထို့နောက် frontend သည် fetch("/api/orders") ကဲ့သို့ relative path ကို ခေါ်သည်။ Cross-origin request မရှိ၊ origin များကြား preflight မရှိ၊ cookie ပြဿနာလည်း မရှိပါ။ Preview နှင့် production ကြား ကွာခြားသော API domain ကို hard-code မလုပ်ရတော့ပါ။

Frontend က backend ကို full URL အစား relative /api path ဖြင့် ခေါ်စေပြီး /api ကို API server သို့ ပို့သော dev proxy ထည့်ပါ။ ထို့နောက် မလိုတော့သော CORS setting များကို ဖယ်ရှားပါ။

မလုပ်သင့်သည်များ

fetch တွင် mode: "no-cors"။ ဘာမျှ ရှောင်ပေးခြင်း မရှိပါ; သင့် code ကို ဗလာ၊ ဖတ်၍ မရသော response ပေးသည်။
CORS ကို ပိတ်သော browser extension များ။ ၎င်းတို့က သင့် browser ကိုသာ ပြောင်းသည်။ ဝင်ကြည့်သူ လူတိုင်းက error ကို မြင်နေရဆဲ ဖြစ်သည်။
Real app များအတွက် public "CORS proxy" ဝန်ဆောင်မှုများ။ ၎င်းတို့ ဖြတ်သန်းသော အရာအားလုံးကို ဖတ်နိုင်ပြီး ပြောင်းနိုင်ကာ ပျက်သွားနိုင်သည်။
Login ရှိသော API တွင် Access-Control-Allow-Origin: *။ ၎င်းသည် credential များနှင့်လည်း အလုပ်မလုပ်ပြီး private data အတွက် မှားသော default ဖြစ်သည်။
Credential ခွင့်ပြုထားစဉ် မည်သည့် Origin header ကိုမဆို ပြန်ထင်ဟပ်ခြင်း။ ၎င်းက မည်သည့် website မဆို သင့်အသုံးပြုသူများ၏ အမည်ဖြင့် login ပါသော request ပြုလုပ်နိုင်စေသည်။ Allowlist ကို သုံးပါ။

AI-built app များတွင် အဖြစ်များသော အကြောင်းများ

အခြေအနေ	ပြင်နည်း
Frontend က secret key ပါသော third-party API ကို ခေါ်သည်	Call ကို backend သို့ ရွှေ့ပါ
Preview တွင် အလုပ်လုပ်၊ published domain တွင် မအောင်မြင်	Published နှင့် custom-domain origin များကို allowlist ထဲ ထည့်ပါ၊ သို့မဟုတ် relative `/api` path များ သုံးပါ
POST၊ PUT သို့မဟုတ် DELETE တွင်သာ error	Preflight မကိုင်တွယ်ရသေး; OPTIONS ကို ကိုင်တွယ်ပြီး ခွင့်ပြုထားသော header များ ထည့်ပါ
Login ထည့်ပြီးနောက် error ပေါ်လာ	Credential များအတွက် origin အတိအကျနှင့် `Allow-Credentials` လိုအပ်
"CORS error" ဖြစ်သော်လည်း Network tab တွင် 500	ဦးစွာ server error ကို ပြင်ပါ
API URL ကို `localhost` တွင် hard-code လုပ်ထား	Relative path များ သို့မဟုတ် environment အလိုက် setting သုံးပါ

Mythex တွင် CORS

Mythex project တွင် website နှင့် API server ရှိလျှင် ၎င်းတို့သည် project တစ်ခုတည်းတွင် service များအဖြစ် run ပြီး preview တွင် ပြောင်းနိုင်သည်။ Frontend သည် backend ကို relative /api path ဖြင့် ခေါ်ရန်၊ development တွင် proxy လုပ်ရန် agent ကို တောင်းဆိုခြင်းသည် CORS ပြဿနာအများစုကို ရှောင်ပေးသည်။ Cross-origin call များ တကယ်လိုအပ်လျှင် console မှ တိကျသော error နှင့် ပါဝင်သော origin များကို agent ကို ပေးပါ။ Published app တွင်လည်း စစ်ဆေးပါ၊ ၎င်း၏ လိပ်စာသည် preview နှင့် ကွဲပြားသည်။ docs ရှိ Multi-service apps နှင့် API backends ကို ကြည့်ပါ၊ ထို့အပြင် ကျွန်ုပ်တို့၏ လမ်းညွှန်များ AI-built app ကို debug လုပ်နည်း နှင့် frontend နှင့် backend ကိုလည်း ကြည့်ပါ။

CORS checklist

Console error အပြည့်အစုံနှင့် မအောင်မြင်သော request ၏ status code ကို ဖတ်ပြီး
ဝှက်ထားသော 404 သို့မဟုတ် 500 မရှိကြောင်း စစ်ပြီး
Secret-key API များကို browser မှ မဟုတ်ဘဲ backend မှ ခေါ်ပြီး
Server သည် ခွင့်ပြုထားသော origin အတိအကျနှင့် Access-Control-Allow-Origin ပို့ပြီး
OPTIONS preflight ကို auth မတိုင်မီ ခွင့်ပြုထားသော method နှင့် header များဖြင့် ဖြေပြီး
Error response များတွင်လည်း CORS header များ ပါပြီး
Credential များ: origin အတိအကျ၊ Allow-Credentials: true၊ မှန်ကန်သော cookie setting
Preview၊ published နှင့် custom-domain origin အားလုံး ပါဝင်ပြီး သို့မဟုတ် relative /api path များ သုံးပြီး
no-cors၊ public proxy နှင့် reflect-any-origin လမ်းဖြတ်များ မသုံးပါ

မေးခွန်းများ

CORS error ဆိုတာ ဘာကို ဆိုလိုသလဲ?

သင့်စာမျက်နှာသည် origin တစ်ခုမှ load ဖြစ်ပြီး အခြား origin တစ်ခုမှ response ကို ဖတ်ရန် ကြိုးစားခဲ့သည်၊ ထို server ၏ response တွင် ခွင့်ပြုသော header များ မပါခဲ့ပေ။ Browser က သင့် code ကို response ဖတ်ခွင့် မပေးဘဲ ပိတ်ဆို့သည်။ ပြင်နည်းမှာ server ပေါ်တွင် ဖြစ်သည် — ၎င်းမဟုတ်ပါက request ကို ပေးပို့ပုံ၌ ဖြစ်သည်၊ frontend code တွင် မဟုတ်ပါ။

Frontend မှ CORS error ကို ပြင်လို့ရသလား?

ရိုးရိုးမပြင်နိုင်ပါ။ mode: 'no-cors' ကဲ့သို့ setting များက response ကို သင့် code မှ ဖုံးကွယ်ရုံသာ ဖြစ်သည်။ server ကို မှန်ကန်သော Access-Control-Allow-Origin header ပို့စေခြင်း၊ ဒါမှမဟုတ် API ကို သင့် backend သို့မဟုတ် same-origin proxy မှ ခေါ်ခြင်းဖြင့် ပြင်ပါ။

Access-Control-Allow-Origin: * သည် ဘေးကင်းသလား?

လူတိုင်း ဖတ်နိုင်သော public data အတွက် ပြဿနာမရှိပါ၊ ဥပမာ login မလိုသော public API။ Cookie သို့မဟုတ် အခြား credential များနှင့် အသုံးပြု၍ မရပါ၊ private API များအတွက် ခွင့်ပြုထားသော origin အတိအကျကို စာရင်းပြုစုသင့်သည်။

ကျွန်ုပ်၏ request သည် Postman သို့မဟုတ် curl တွင် အလုပ်လုပ်သော်လည်း browser တွင် ဘာကြောင့် မအောင်မြင်သလဲ?

CORS ကို browser များက သာ ပြဌာန်းသည်။ Postman နှင့် curl ကဲ့သို့ tool များက မကိုင်တွယ်ပါ၊ ထို့ကြောင့် request သည် ထိုနေရာတွင် အောင်မြင်ပေမဲ့ စာမျက်နှာ JavaScript မှ ပေးပို့သောအခါ ပိတ်ဆို့ခံရနိုင်သည်။

Preflight request ဆိုတာ ဘာလဲ?

ရိုးရှင်းမဟုတ်သော request များအတွက်၊ ဥပမာ JSON POST သို့မဟုတ် Authorization header ပါသော request များ၊ browser က ဦးစွာ OPTIONS request ပို့ပြီး ဘယ် method နှင့် header များ ခွင့်ပြုသည်ကို server ကို မေးသည်။ ထို OPTIONS request မအောင်မြင်ခြင်း သို့မဟုတ် မှန်ကန်သော header မပါခြင်းဖြစ်လျှင် တကယ့် request ကို ဘယ်တော့မှ မပို့ပါ။