Hvernig á að laga CORS-villur (og af hverju þær koma upp)

CORS-villa þýðir að vefsíðan þín reyndi að lesa svar frá öðrum uppruna (öðru léni, porti eða samskiptareglu), og sá þjónn sendi ekki hausa sem segja að það sé leyfilegt. Vafrar stöðva svarið til að vernda notendur. Þú lagar það á þjóninum með því að skila Access-Control-Allow-Origin-haus fyrir uppruna síðunnar þinnar og taka við OPTIONS forbeiðnum, eða þú forðast það með því að senda beiðnina í gegnum þinn eigin bakenda á sama uppruna.

Hún er ein ruglingslegasta villan í vefþróun því beiðnin nær oft til þjónsins án vandræða. Þessi leiðbeining útskýrir hvað er að gerast og hvernig á að laga hvert afbrigði.

Hvað „uppruni“ þýðir

Uppruni (origin) er samsetning samskiptareglu, lénsins og ports:

Vafrar fylgja sömu-uppruna-reglunni: JavaScript á síðu getur frjálslega lesið svör frá eigin uppruna, en ekki frá öðrum. CORS (Cross-Origin Resource Sharing) er kerfið sem gerir þjóni kleift að samþykkja: „svör frá mér mega síður frá þessum uppruna lesa.“

Tvær afleiðingar koma fólki oft á óvart:

• Beiðnin nær oft til þjónsins. CORS stöðvar yfirleitt kóðann þinn í að lesa svarið, ekki þjóninn í að taka við beiðninni. POST gæti hafa verið vistað þótt þú sæir villu.
• Aðeins vafrar framfylgja því. curl, Postman og kóði á þjóni hunsa CORS alveg. Þess vegna segir „virkar í Postman“ þér ekkert um CORS.

Skref 1: Lestu nákvæmu villuna

Opnaðu þróunarverkfæri (hægrismelltu → Inspect), farðu í Console og lestu alla villuna. Orðalag Chrome segir þér hvers konar vandamál þú ert með:

Opnaðu síðan Network-flipann, finndu beiðnina sem mistókst (og allar OPTIONS-beiðnir á undan henni) og skoðaðu stöðukóðann og svarhausana.

Athugaðu stöðukóðann fyrst. Margar „CORS-villur“ eru í raun villa á þjóninum í dulargervi. Ef þjónninn hrynur eða skilar 404 vantar oft CORS-hausa í villusvarið, svo vafrinn tilkynnir CORS í stað raunverulegs vandamáls. Lagaðu 500- eða 404-villuna og CORS-villan gæti horfið.

Skref 2: Ákveddu hvort vafrinn eigi yfirhöfuð að kalla á þetta API

Áður en þú bætir við hausum skaltu spyrja: á vafrinn að kalla á þetta API beint?

• API frá þriðja aðila sem krefst leyndarlykils (OpenAI, Stripe-leyndarlykill, flestar tölvupóstþjónustur) ætti aldrei að kalla úr vafranum. Lykillinn væri sýnilegur hverjum gesti. Kallaðu á það úr bakendanum í staðinn, og CORS-vandamálið hverfur, því samskipti þjóns við þjón falla ekki undir CORS. Sjáðu hvernig á að geyma API-lykla örugga.
• API frá þriðja aðila sem þú stjórnar ekki og sendir ekki CORS-hausa er ekki hægt að laga frá þinni hlið. Kallaðu á það úr bakendanum.
• Þitt eigið API er hægt að laga með því að stilla það rétt. Haltu áfram hér fyrir neðan.

Skref 3: Lagaðu það á þjóninum þínum

Þjónninn verður að bæta réttum hausum við svör sín, þar með talin villusvör.

Fyrir sjálfa beiðnina sendir þú:

• Access-Control-Allow-Origin: https://myapp.com (nákvæman uppruna framendans, án skástriks í lokin)
• Vary: Origin, ef gildið fer eftir því hvaða uppruni spurði

Fyrir OPTIONS forbeiðnina svarar þú með árangursstöðu (200 eða 204) og:

• Access-Control-Allow-Origin: https://myapp.com
• Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
• Access-Control-Allow-Headers: Content-Type, Authorization (hvern sérsniðinn haus sem þú sendir)
• Valkvætt Access-Control-Max-Age: 600, svo vafrinn geymi forbeiðnina um tíma

Flest rammar eru með pakka eða stillingu sem gerir þetta. Í Express er það cors-pakkinn; í FastAPI CORSMiddleware; í ASP.NET Core AddCors; í Spring @CrossOrigin eða CORS-stilling. Dæmigerð Express-uppsetning:

import cors from "cors";

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

Settu CORS-meðhöndlun fyrir leiðirnar þínar og auðkenninguna, svo að forbeiðnir (sem bera enga innskráningu) séu ekki hafnaðar með 401.

Með smíðatóli gervigreindar skaltu lýsa uppsetningunni nákvæmlega:

Framendinn á https://myapp.com kallar á API-ið á https://api.myapp.com og fær „Response to preflight request doesn't pass access control check“. Stilltu CORS á API-inu þannig að það leyfi nákvæmlega https://myapp.com og forskoðunaruppruna, leyfi GET, POST, PATCH, DELETE með Content-Type og Authorization-hausum, svari OPTIONS áður en auðkenning fer fram, og hafi CORS-hausa líka á villusvörum.

Skref 4: Meðhöndlaðu vafrakökur og auðkenningu

Sendi framendinn vafrakökur (til dæmis innskráningarsetu) á annan uppruna þurfa báðar hliðar að vera sammála:

• Framendinn stillir credentials: "include" á fetch, eða withCredentials: true í axios.
• Þjónninn sendir Access-Control-Allow-Credentials: true.
• Access-Control-Allow-Origin þjónsins verður að vera nákvæmi uppruninn, ekki *.

Vafrakökur milli vefsvæða þurfa líka SameSite=None; Secure á kökunni, og sumir vafrar takmarka kökur frá þriðja aðila enn frekar. Það er ein ástæða enn til að velja aðferðina í skrefi 5.

Skref 5: Forðastu CORS með uppsetningu á sama uppruna

Oft er hreinasta lausnin að gera engar beiðnir milli uppruna. Þjónaðu API-inu frá sama uppruna og síðan, til dæmis á https://myapp.com/api/...:

• Í þróun geta flestir þróunarþjónar virkað sem proxy. server.proxy-stillingin í Vite getur sent /api áfram á bakendann þinn á öðru porti, svo vafrinn talar aðeins við einn uppruna.
• Í framleiðslu leiðirðu /api á bakendann í gegnum endurskrifun eða proxy-stillingar hýsingarinnar, eða þjónar framendanum og API-inu af einum þjóni.

Framendinn kallar þá á hlutfallslega slóð eins og fetch("/api/orders"). Þar er engin beiðni milli uppruna, engin forbeiðni milli uppruna og engin vandamál með vafrakökur. Það þýðir líka að þú þarft ekki að kóða API-lén sem er ólíkt milli forskoðunar og framleiðslu.

Breyttu framendanum þannig að hann kalli á bakendann með hlutfallslegum /api-slóðum í stað fullrar URL, og settu upp þróunarproxy þannig að /api sendist áfram á API-þjóninn. Fjarlægðu síðan CORS-stillingar sem við þurfum ekki lengur.

Það sem þú ættir ekki að gera

• mode: "no-cors" í fetch. Það sniðgengur ekkert; það gefur kóðanum þínum tómt, ólæsilegt svar.
• Viðbætur í vafra sem slökkva á CORS. Þær breyta aðeins þínum vafra. Hver gestur sér samt villuna.
• Opin „CORS-proxy“-þjónusta fyrir raunveruleg öpp. Þær geta lesið og breytt öllu sem fer í gegnum þær, og þær liggja niðri.
• Access-Control-Allow-Origin: * á API sem notar innskráningar. Það virkar ekki með auðkenningu hvort sem er, og er röng sjálfgefin stilling fyrir einkagögn.
• Endurspegla hvaða Origin-haus sem er með leyfðri auðkenningu. Það gerir hvaða vefsíðu sem er kleift að gera innskráðar beiðnir fyrir hönd notenda þinna. Notaðu lista yfir leyfða uppruna.

Algengar orsakir í öppum sem gervigreind hefur smíðað

CORS í Mythex

Í Mythex-verkefni sem hefur vefsíðu og API-þjón keyra báðir sem þjónustur í sama verkefni og þú getur skipt á milli þeirra í forskoðuninni. Ef þú biður agentinn um að láta framendann kalla á bakendann í gegnum hlutfallslega /api-slóð, proxy-aða í þróun, forðastu flest CORS-vandamál. Ef þú þarft virkilega köll milli uppruna skaltu gefa agentinum nákvæmu villuna úr stjórnborðinu og uppruna sem málið varðar. Athugaðu niðurstöðuna líka á birta appinu, því vistfang þess er annað en í forskoðuninni. Sjáðu Fjölþjónustuöpp og API-bakendar í skjölunum, og leiðbeiningar okkar um villuleit í appi sem gervigreind smíðaði og framenda á móti bakenda.

Gátlisti fyrir CORS

• Lesin full villan í stjórnborðinu og stöðukóði misheppnaðrar beiðni
• Útilokað falið 404 eða 500
• API með leyndarlykli kallað úr bakendanum, ekki vafranum
• Þjónninn sendir Access-Control-Allow-Origin með nákvæmum leyfðum uppruna
• OPTIONS-forbeiðnin svarar með leyfðum aðferðum og hausum, fyrir auðkenningu
• CORS-hausar eru á villusvörum líka
• Auðkenning: nákvæmur uppruni, Allow-Credentials: true og réttar stillingar fyrir vafrakökur
• Forskoðunar-, birtir og sérsniðnir uppruna eru allir þaktir, eða hlutfallslegar /api-slóðir notaðar
• Engin no-cors, opin proxy eða „endurspegla hvaða uppruna sem er“-flýtileiðir

Spurningar