Si të rregulloni gabimet CORS (dhe pse ndodhin)

Një gabim CORS do të thotë që faqja juaj e uebit u përpoq të lexojë një përgjigje nga një origjinë tjetër (domain, port ose protokoll tjetër), dhe ai server nuk dërgoi header-a që thonë se kjo është e lejuar. Shfletuesit e bllokojnë përgjigjen për të mbrojtur përdoruesit. E rregulloni në server, duke kthyer një header Access-Control-Allow-Origin për origjinën e sajtit tuaj dhe duke trajtuar kërkesat preflight OPTIONS, ose e shmangni duke e dërguar kërkesën përmes back end-it tuaj në të njëjtën origjinë.

Është një nga gabimet më të ngatërruara në zhvillimin web, sepse kërkesa shpesh arrin te serveri pa problem. Ky udhëzues shpjegon çfarë ndodh dhe si rregullohet secili variant.

Çfarë do të thotë "origjinë"

Një origjinë është kombinimi i protokollit, domain-it dhe portit:

Shfletuesit ndjekin politikën e së njëjtës origjinë: JavaScript në një faqe mund të lexojë lirisht përgjigjet nga origjina e vet, por jo nga të tjerët. CORS (Cross-Origin Resource Sharing) është sistemi që lejon një server të pranojë me vetëdije: "përgjigjet e mia mund t'i lexojnë faqet nga këto origjina."

Dy pasoja befasojnë shumë njerëz:

• Kërkesa shpesh arrin te serveri. CORS zakonisht e bllokon kodin tuaj nga leximi i përgjigjes, jo serverin nga marrja e kërkesës. Një POST mund të jetë ruajtur edhe pse keni parë një gabim.
• Vetëm shfletuesit e zbatojnë. curl, Postman dhe kodi i serverit e injorojnë plotësisht CORS. Prandaj "funksionon në Postman" nuk të tregon asgjë për CORS.

Hapi 1: Lexoni gabimin e saktë

Hapni mjetet e zhvilluesit (klikoni me të djathtën → Inspect), shkoni te Console, dhe lexoni mesazhin e plotë. Formulimi i Chrome tregon cilin problem keni:

Pastaj hapni skedën Network, gjeni kërkesën që dështoi (dhe çdo kërkesë OPTIONS para saj), dhe shikoni kodin e statusit dhe header-at e përgjigjes.

Kontrolloni së pari kodin e statusit. Shumë "gabime CORS" janë në fakt një gabim serveri i maskuar. Nëse serveri rrëzohet ose kthen 404, përgjigja e tij e gabimit shpesh nuk ka header-a CORS, kështu që shfletuesi raporton CORS në vend të problemit real. Rregulloni 500 ose 404-n, dhe gabimi CORS mund të zhduket.

Hapi 2: Vendosni nëse duhet ta thirrni fare atë API nga shfletuesi

Përpara se të shtoni header-a, pyesni: a duhet që shfletuesi ta thërrasë drejtpërdrejt këtë API?

• Një API e palës së tretë që kërkon një çelës sekret (OpenAI, çelësi sekret i Stripe, shumica e shërbimeve të email-it) s'duhet të thirret kurrë nga shfletuesi. Çelësi do të ishte i dukshëm për çdo vizitor. Thirreni nga back end-i juaj, dhe problemi CORS zhduket, sepse kërkesat server-to-server nuk i nënshtrohen CORS. Shihni si t'i mbani çelësat API të sigurt.
• Një API e palës së tretë që nuk e kontrolloni dhe që nuk dërgon header-a CORS nuk mund të rregullohet nga ana juaj. Thirreni nga back end-i juaj.
• API juaj mund të rregullohet duke e konfiguruar siç duhet. Vazhdoni më poshtë.

Hapi 3: Rregulloni në serverin tuaj

Serveri duhet të shtojë header-at e duhur te përgjigjet e tij, duke përfshirë përgjigjet e gabimit.

Për kërkesën aktuale, dërgoni:

• Access-Control-Allow-Origin: https://myapp.com (origjina e saktë e front end-it tuaj, pa shenjë / në fund)
• Vary: Origin, nëse vlera varet nga cila origjinë pyet

Për kërkesën preflight OPTIONS, përgjigjuni me një status suksesi (200 ose 204) dhe:

• Access-Control-Allow-Origin: https://myapp.com
• Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
• Access-Control-Allow-Headers: Content-Type, Authorization (çdo header i personalizuar që dërgoni)
• Opsionalisht Access-Control-Max-Age: 600, që shfletuesi ta ruajë preflight-in për pak kohë

Shumica e kornizave kanë një paketë ose cilësim që e bën këtë. Në Express, paketa cors; në FastAPI, CORSMiddleware; në ASP.NET Core, AddCors; në Spring, @CrossOrigin ose një konfigurim CORS. Një konfigurim tipik në Express:

import cors from "cors";

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

Vendoseni trajtimin e CORS përpara rrugëve dhe autentikimit tuaj, që kërkesat preflight (të cilat nuk mbajnë hyrje) të mos refuzohen me 401.

Me një ndërtues AI, përshkruajeni konfigurimin saktë:

Front end-i te https://myapp.com thërret API-n te https://api.myapp.com dhe merr "Response to preflight request doesn't pass access control check". Konfiguro CORS te API-ja për të lejuar saktësisht https://myapp.com dhe origjinën e pamjes paraprake, lejo GET, POST, PATCH, DELETE me header-at Content-Type dhe Authorization, trajto OPTIONS para autentikimit, dhe përfshi header-at CORS edhe te përgjigjet e gabimit.

Hapi 4: Trajtoni cookie-t dhe kredencialet

Nëse front end-i juaj dërgon cookie (për shembull një sesion hyrjeje) te një origjinë tjetër, të dyja anët duhet të bien dakord:

• Front end-i vendos credentials: "include" te fetch, ose withCredentials: true në axios.
• Serveri dërgon Access-Control-Allow-Credentials: true.
• Access-Control-Allow-Origin i serverit duhet të jetë origjina e saktë, jo *.

Cookie-t ndërsite kërkojnë gjithashtu SameSite=None; Secure te cookie-ja, dhe disa shfletues kufizojnë më tej cookie-t e palëve të treta. Kjo është një arsye tjetër për të preferuar qasjen në Hapin 5.

Hapi 5: Shmangeni CORS me një konfigurim të së njëjtës origjinë

Shpesh zgjidhja më e pastër është të mos bëni fare kërkesa ndër-origjinë. Shërbeni API-n nga e njëjta origjinë me faqen, për shembull te https://myapp.com/api/...:

• Gjatë zhvillimit, shumica e serverave të zhvillimit mund të bëjnë proxy. Cilësimi server.proxy i Vite mund të përcjellë /api te back end-i juaj në një port tjetër, kështu që shfletuesi komunikon vetëm me një origjinë.
• Në prodhim, drejtoni /api te back end-i përmes cilësimeve të rewrite ose proxy të hostit tuaj, ose shërbeni front end-in dhe API-n nga një server i vetëm.

Front end-i pastaj thërret një rrugë relative si fetch("/api/orders"). Nuk ka kërkesë ndër-origjinë, nuk ka preflight ndër-origjinë, dhe nuk ka probleme me cookie. Gjithashtu do të thotë që nuk e fiksoni një domain API që ndryshon midis pamjes paraprake dhe prodhimit.

Ndrysho front end-in që të thërrasë back end-in me rrugë relative /api në vend të një URL të plotë, dhe vendos një proxy zhvillimi që /api të përcjellë te serveri i API-t. Pastaj hiq çdo cilësim CORS që nuk na nevojitet më.

Çfarë të mos bëni

• mode: "no-cors" te fetch. Nuk kalon asgjë; i jep kodit tuaj një përgjigje boshe dhe të palexueshme.
• Shtesa shfletuesi që çaktivizojnë CORS. Ndryshojnë vetëm shfletuesin tuaj. Çdo vizitor ende sheh gabimin.
• Shërbime publike "CORS proxy" për aplikacione reale. Mund të lexojnë dhe ndryshojnë gjithçka që kalon nga ato, dhe bien.
• Access-Control-Allow-Origin: * në një API që përdor hyrje. Nuk funksionon me kredenciale në çdo rast, dhe është parazgjedhja e gabuar për të dhëna private.
• Pasqyrimi i çdo header-i Origin me kredenciale të lejuara. Kjo i lejon çdo faqeje uebi të bëjë kërkesa të kyçura në emër të përdoruesve tuaj. Përdorni një listë të lejuarish.

Shkaqe të zakonshme në aplikacionet e ndërtuara me AI

CORS në Mythex

Kur një projekt Mythex ka një sajt dhe një server API, të dy ekzekutohen si shërbime në të njëjtin projekt, dhe mund të ndërroni mes tyre në pamjen paraprake. Kërkimi që agjenti ta bëjë front end-in të thërrasë back end-in përmes një rruge relative /api, e proxy-uar gjatë zhvillimit, shmang shumicën e problemeve CORS. Nëse ju duhen thirrje ndër-origjinë, jepni agjentit gabimin e saktë nga konsola dhe origjinat e përfshira. Kontrolloni rezultatin edhe në aplikacionin e publikuar, sepse adresa e tij ndryshon nga ajo e pamjes paraprake. Shihni Shërbimet e shumëfishta dhe Back-end-et API në dokumentacion, dhe udhëzuesit tanë për diagnostikimin e një aplikacioni të ndërtuar me AI dhe front end kundrejt back end.

Lista e kontrollit për CORS

• U lexua gabimi i plotë i konsolës dhe kodi i statusit të kërkesës që dështoi
• U përjashtua një 404 ose 500 i fshehur
• API-t me çelës sekret thirren nga back end-i, jo nga shfletuesi
• Serveri dërgon Access-Control-Allow-Origin me origjina të sakta të lejuara
• Preflight OPTIONS përgjigjet me metoda dhe header-a të lejuar, përpara autentikimit
• Header-at CORS janë të pranishëm te përgjigjet e gabimit
• Kredencialet: origjinë e saktë, Allow-Credentials: true, dhe cilësimet e duhura të cookie-ve
• Origjinat e pamjes paraprake, të publikuara dhe të domain-it të personalizuar janë të mbuluara, ose përdoren rrugë relative /api
• Nuk përdoren no-cors, proxy publikë ose shkurtesa që pasqyrojnë çdo origjinë

Pyetje