Heim
» Grundvallarþekking
»
Hvernig á að laga CORS-fyrirsögninn Access-Control-Allow-Origin sem vantar í Express.js
Hvernig á að laga CORS-fyrirsögninn Access-Control-Allow-Origin sem vantar í Express.js
Ef vafri segir CORS header 'Access-Control-Allow-Origin' missing, þá er mikilvæga vísbendingin ekki sú að Express.js hafi mistekist að taka við beiðninni. Vafriinn er að segja þér að svarið hafi ekki innihaldið CORS-fyrirsögn sem heimilar uppruna síðunnar að lesa svarið. Lagfæringin á því heima á netþjóninum eða proxy-þjóni sem þú stjórnar, ekki í einhverjum handahófskenndum stillingum á biðlaranum.
Dæmi til útskýringar sem notað er í þessum leiðarvísir: ímyndaðu þér verkefnastjórnunarspjald (task dashboard) sem keyrir á http://localhost:5173 og kallar á Express API á http://localhost:3000/api/tasks. Vafriinn kemur í veg fyrir að JavaScript geti lesið API-svarið vegna þess að API-ið skilar ekki Access-Control-Allow-Origin. Þetta er ímynduð kennsludæmi, ekki fullyrðing um raunverulega prófun, vöru eða útfærslu.
Eins og staðfest var þann 11. september 2026, þá listar opinber Express CORS-miðlungsforritsskjöl cors útgáfu 2.8.6 og lýsir því sem miðlungsforriti (middleware) sem stillir CORS-svarfyrirsagnir. Núverandi Express pakkalistinn er í 5.x kynslóðinni, svo þessi leiðarvísir leggur áherslu á miðlungsforrit á forritsstigi í stað þess að treysta á eldri mynstur fyrir almennt rásarval (wildcard route patterns).
Hvað villan þýðir í raun
Vefsíða hefur uppruna sem samanstendur af samskiptareglum (scheme), hýsli (host) og gátt (port). Í dæminu eru http://localhost:5173 og http://localhost:3000 ólíkir upprunar vegna þess að gáttirnar eru ólíkar. Sama-uppruna stefna vafra (same-origin policy) kemur venjulega í veg fyrir að JavaScript á einum uppruna geti lesið auðlindir frá öðrum nema marknetþjónninn skili viðeigandi Cross-Origin Resource Sharing (CORS) fyrirsögnum.
Skjölun MDN fyrir þessa nákvæmu villu útskýrir að svarið vanti nauðsynlegu Access-Control-Allow-Origin fyrirsögnina. Ef þú stjórnar netþjóninum ættir þú að stilla uppruna beiðnaraðila sem leyfilegan uppruna. Fyrir opinber, óauðkennd (non-credentialed) API getur * verið viðeigandi; fyrir einkaaðgang eða auðkennd (credentialed) API ætti að nota ákveðna trausta uppruna. Sjá útskýringu MDN á villunni þar sem Access-Control-Allow-Origin vantar.
Skref 1: Staðfestu að CORS sé vandamálið og auðkenndu nákvæman uppruna
AI-búin mynd, ekki raunveruleg skjámynd: vafri tilkynnir að Access-Control-Allow-Origin vanti í Express-svarinu.
Opnaðu þróunarverkfæri vafrans og skoðaðu bæði Console og Network gluggana. Skráðu framenda-upprunann nákvæmlega eins og vafriinn sendir hann. Í okkar ímynduðu tilviki er það http://localhost:5173.
Ekki minnka uppruna niður í bara hýsilnafn. Þetta eru ólíkir upprunar: http://localhost:5173, http://localhost:3000, http://127.0.0.1:5173 og https://localhost:5173. Leyfislisti í framleiðsluumhverfi verður einnig að greina á milli https://app.example.com og annarra samskiptareglna, hýsla, gátta eða undirlénis nema þú leyfir þá viljandi.
Ef API-svarið er 404, 500, endurstilling, auðkenningarbilun eða villusíða sem proxy hefur búið til, skoðaðu það svar líka. CORS-fyrirsagnir þurfa að vera til staðar í svarinu sem vafriinn fær í raun og veru. Lagfæring á forritsrás hjálpar ekki ef öfugur proxy, CDN, hleðslujafnari eða villumeðhöndlari skilar öðru svari án fyrirsagnarinnar.
Skref 2: Settu upp og hlaðið opinbera Express CORS-miðlungsforritið
AI-búin mynd, ekki raunveruleg skjámynd: settu upp cors miðlungsforritið sem Express viðheldur og hlaðið því inn í netþjóninn.
Fyrir flest Express forrit er lausnin sem veldur minnstum villum cors miðlungsforritið sem Express verkefnið viðheldur. Opinbera Express miðlungsforritasíðan listar það meðal miðlungsforrita sem Express.js teymið viðheldur. Settu það upp í API verkefninu þínu:
Að setja app.use(cors(corsOptions)) á undan API rásunum skiptir máli vegna þess að Express vinnur miðlungsforrit í röð. Miðlungsforritið þarf tækifæri til að bæta við svarfyrirsögnum áður en rás eða fyrra miðlungsforrit endar beiðnina.
Fyrir alveg opinbert API sem notar ekki auðkenningarupplýsingar, notar app.use(cors()) sjálfgefna frjálsa hegðun miðlungsforritsins varðandi uppruna. Það er þægilegt, en ætti ekki að vera sjálfgefin valkostur í framleiðsluumhverfi. MDN mælir með að takmarka Access-Control-Allow-Origin við lágmarks uppruna og auðlindir sem þarf. Sjá öryggisleiðbeiningar MDN um CORS.
Leyfðu nokkra þekkta uppruna án þess að leyfa öllum
Algeng uppsetning í framleiðsluumhverfi hefur staðbundna framenda, staging framenda og framleiðslu framenda. Notaðu leyfislista og staðfestu innkomandi uppruna:
const allowedOrigins = new Set([
'http://localhost:5173',
'https://staging.example.com',
'https://app.example.com'
]);
const corsOptions = {
origin(origin, callback) {
if (!origin || allowedOrigins.has(origin)) {
callback(null, true);
return;
}
callback(new Error('Origin not allowed by CORS'));
}
};
app.use(cors(corsOptions));
!origin greinin leyfir biðlarum sem senda ekki Origin fyrirsögn, svo sem mörgum netþjóns-til-netþjóns beiðnum og skipanalínutólum. Hvort þú vilt þessa hegðun er ákvörðun um stefnu forritsins; CORS er ekki auðkenning.
Skref 4: Staðfestu einföldu beiðnina og allar forspurningar (preflight)
AI-búin mynd, ekki raunveruleg skjámynd: staðfestu að vafrið fái væntanlega CORS-fyrirsögn og að OPTIONS forspurning gangi eftir.
Endurhlaðið framenduna og skoðið Network gluggann. Sigurskilyrðið er ekki bara 200 staða. Athugaðu svarfyrirsagnirnar. Í okkar ímynduða tilviki ætti API-svarið að innihalda upprunagildi sem jafngildir:
Sumar kross-uppruna beiðnir kalla á forspurn (preflight): vafriinn sendir OPTIONS beiðni á undan raunverulegu beiðninni til að athuga hvort aðferðin og fyrirsagnirnar séu leyfðar. Beiðnir sem nota aðferðir eins og PUT eða DELETE, eða ákveðnar sérsniðnar/beiðnaraðila fyrirsagnir, þurfa oft forspurn. Þegar cors er sett upp sem miðlungsforrit á forritsstigi með app.use(cors(...)), segja opinberu Express skjölin að forspurnarbeiðnir séu meðhöndlaðar fyrir allar rásir.
Þú getur einnig skoðað fyrirsagnir utan vafra án þess að fullyrða að skipanalínubiðlarinn framfylgi CORS:
Þetta er gagnlegt til að sjá hvað netþjónninn skilar, en vel heppnuð curl eða API-biðlarabeiðni sannar ekki að vafra-CORS sé rétt stillt. Express CORS skjölunin nefna sérstaklega að CORS er framfylgt af vöfrum; biðlarar sem eru ekki vafrar beita ekki sömu lestur-takmörkun.
Auðkenndar beiðnir: blandu ekki auðkenningarupplýsingum við almennt uppruna-vildarmerki
Ef framendan verður að senda smákökur eða HTTP auðkenningu kross-uppruna, þurfa báðar hliðar samhæfðar stillingar. Á Express hliðinni, stilltu ákveðinn traustan uppruna og virkjaðu auðkenningarupplýsingar:
Á vafrahliðinni notar fetch beiðni sem þarf smákökur venjulega credentials: 'include'. Ekki breyta netþjónsupprunanum í * fyrir auðkennda beiðni. Vafrar samþykkja ekki almennt Access-Control-Allow-Origin vildarmerki saman við auðkennd CORS á þann hátt sem forritarar búast oft við, og ótakmarkaður uppruni væri einnig slæmt öryggismark.
Af hverju algengar „lagfæringar“ mistakast
Tilraun
Af hverju það leysir ekki raunverulega vandamálið
Betri nálgun
Setja mode: 'no-cors' í fetch
Svarið verður ógagnsætt (opaque), svo JavaScript getur ekki lesið svarmegin eða flestar fyrirsagnir.
Stilla CORS á netþjóninum sem þú stjórnar.
Prófa aðeins í Postman eða curl
Þessir biðlarar framfylgja ekki vafra-CORS stefnu.
Skoðaðu raunverulega beiðni og svarfyrirsagnir í vafra.
Nota Access-Control-Allow-Origin: * alls staðar
Það er óþarfa víðtækt fyrir einkaaðgang API og ósamhæft við algengar auðkenndar uppsetningar.
Leyfðu aðeins trausta uppruna þegar API-ið er ekki alveg opinbert.
Bæta við mörgum Access-Control-Allow-Origin fyrirsögnum
Vafrar búast við einu leyfilegu upprunagildi, ekki mörgum eintökum eða kommu-aðskildum upprunalista.
Staðfestu beiðniupprunann og skilaðu einu passandi gildi.
Breyta framendakóða endurtekið
Fyrirsögnin sem vantar er í netþjónssvarinu.
Laga Express eða proxy sem býr til lokasvarið.
Þegar Express kóðinn lítur rétt út en villan er enn til staðar
Ef fjögur skrefin hér að ofan leysa ekki villuna, rekja alla beiðnarleiðina í stað þess að bæta blindlega við fleiri fyrirsögnum.
Athugaðu röð miðlungsforrita. CORS miðlungsforrit ætti að keyra á undan rásunum eða meðhöndlum sem enda svarið.
Athugaðu endurstillingar. Vafrið gæti verið að fá svar frá öðru URL eða uppruna eftir endurstillingu.
Athugaðu proxy/CDN hegðun. Nginx, gátt, serverless pallur eða CDN getur bætt við, fjarlægt, tvöfaldað eða skipt út fyrirsögnum.
Athugaðu svar við villum. Venjulegt 200 svar getur innihaldið CORS fyrirsagnir en 401, 404 eða 500 svar gerir það ekki.
Athugaðu bókstaflega upprunann. Samskiptareglur, hýsilnafn og gátt skipta öllu máli; localhost og 127.0.0.1 eru ekki skiptanleg fyrir CORS samsvörun.
Handvirkar fyrirsagnir versus cors miðlungsforritið
Þú getur stillt CORS fyrirsagnir handvirkt með Express svar API-um, en það er auðvelt að gleyma forspurnarhegðun, auðkenningarreglum, dýnamískri upprunasamsvörun, Vary: Origin eða villuleiðum. Opinbera cors miðlungsforritið býður þegar upp á valkostum fyrir origin, aðferðir, leyfðar fyrirsagnir, opinberar fyrirsagnir, auðkenningarupplýsingar, forspurnarhegðun og hámarksaldur. Fyrir flest Express verkefni heldur notkun þess miðlungsforrits stefnunni skýrari og auðveldari til að yfirfara.
Ef þú útfærir dýnamíska upprunalogík sjálfur, endurspeglaðu aldrei hvert innkomandi Origin gildi sjálfkrafa bara vegna þess að það er til staðar. Staðfestu það gegn traustum mengi. MDN varar við því að ótakmarkaður kross-uppruna lestur geti lekið gögnum, sérstaklega þegar auðkenningarupplýsingar eru í boði.
Hagnýt framleiðslu athugunarlisti
Listaðu nákvæma framenda-uppruna sem ættu að geta lesið API-ið.
Notaðu HTTPS uppruna í framleiðsluumhverfi og haltu þróunarupprunum aðskildum.
Settu upp CORS miðlungsforrit á undan vernduðum API rásunum sem þurfa það.
Notaðu ákveðna uppruna fyrir einkaaðgang eða auðkennd endapunkta.
Staðfestu bæði venjuleg svör og forspurnar OPTIONS svör í vafra.
Staðfestu bilunarleiðir eins og 401, 404 og 500 svör ef þau geta verið skilað kross-uppruna.
Meðhöndlaðu CORS sem vafra-lestur stefnu, ekki sem auðkenningu eða heimild.
Í ímynduðu verkefnastjórnunarspjalds tilviki er varanlega lagfæringin einföld: auðkenndu nákvæman uppruna framendunnar, stilltu Express til að skila samsvarandi CORS fyrirsögn, leyfðu miðlungsforriti á forritsstigi að meðhöndla forspurn, og staðfestu fyrirsagnirnar í svarinu sem vafrið fær í raun og veru. Ef fyrirsögnin vantar enn eftir það, er næsti grunaði yfirleitt röð miðlungsforrita eða innviðir á milli vafra og Express, ekki fetch kall framendunnar sjálft.