Како да ги поправите CORS грешките (и зошто се јавуваат)

CORS грешка значи дека вашата веб-страница се обидела да прочита одговор од друг origin (друг домен, порта или протокол), а тој сервер не испратил заглавија што велат дека е дозволено. Прелистувачите го блокираат одговорот за да ги заштитат корисниците. Поправката е на серверот: вратете заглавие Access-Control-Allow-Origin за origin-от на вашиот сајт и ракувајте со OPTIONS preflight барања, или ја избегнувате така што барањето ќе го испраќате преку сопствен бекенд на ист origin.

Тоа е една од најзбунувачките грешки во веб-развојот, бидејќи барањето често стигнува до серверот без проблем. Овој водич објаснува што се случува и како да се поправи секоја варијанта.

Што значи „origin“

Origin е комбинација од протокол, домен и порта:

Прелистувачите ја следат same-origin политиката: JavaScript на страницата слободно може да чита одговори од сопствениот origin, но не и од други. CORS (Cross-Origin Resource Sharing) е системот со кој серверот се согласува: „одговорите од мене може да ги читаат страници од овие origin-и.“

Две последици изненадуваат луѓе:

• Барањето често стигнува до серверот. CORS обично го блокира вашиот код да го чита одговорот, а не серверот да го прими барањето. POST може да е зачувано, иако сте видели грешка.
• Само прелистувачите го спроведуваат. curl, Postman и серверскиот код го игнорираат CORS целосно. Затоа „работи во Postman“ ништо не ви кажува за CORS.

Чекор 1: Прочитајте ја точната грешка

Отворете ги алатките за програмери (десен клик → Inspect / Прегледај), одете на Console / Конзола и прочитајте ја целата порака. Формулацијата во Chrome ви кажува кој проблем имате:

Потоа отворете го табот Network / Мрежа, најдете го неуспешното барање (и секое OPTIONS барање пред него) и погледнете го статус кодот и заглавијата на одговорот.

Прво проверете го статус кодот. Многу „CORS грешки“ всушност се серверска грешка во маска. Ако серверот падне или врати 404, неговиот одговор со грешка често нема CORS заглавија, па прелистувачот пријавува CORS наместо вистинскиот проблем. Поправете ја грешката 500 или 404, и CORS грешката можеби исчезнува.

Чекор 2: Одлучете дали воопшто треба да се повикува тој API од прелистувачот

Пред да додавате заглавија, прашајте: треба ли прелистувачот да го повикува овој API директно?

• API од трета страна што бара тајен клуч (OpenAI, Stripe secret key, повеќето услуги за е-пошта) никогаш не треба да се повикува од прелистувачот. Клучот би бил видлив за секој посетител. Повикајте го од вашиот бекенд, и CORS проблемот исчезнува, бидејќи барањата од сервер до сервер не се предмет на CORS. Видете како да ги чувате API клучевите безбедни.
• API од трета страна што не го контролирате и не испраќа CORS заглавија не може да се поправи од ваша страна. Повикајте го од вашиот бекенд.
• Вашиот API може да се поправи со правилно конфигурирање. Продолжете подолу.

Чекор 3: Поправете го на вашиот сервер

Серверот мора да ги додава вистинските заглавија на своите одговори, вклучително и одговорите со грешки.

За самото барање испратете:

• Access-Control-Allow-Origin: https://myapp.com (точниот origin на вашиот фронтенд, без коса црта на крајот)
• Vary: Origin, ако вредноста зависи од тоа кој origin прашал

За preflight OPTIONS барањето одговорете со успешен статус (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 (секое прилагодено заглавие што го испраќате)
• По избор Access-Control-Max-Age: 600, за прелистувачот да го кешира preflight-от подолго

Повеќето фрејмворци имаат пакет или поставка што го прави ова. Во Express, пакетот cors; во FastAPI, CORSMiddleware; во ASP.NET Core, AddCors; во Spring, @CrossOrigin или CORS конфигурација. Типично поставување во Express:

import cors from "cors";

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

CORS ракувањето ставете пред вашите рути и автентикација, за preflight барањата (кои не носат најава) да не бидат одбиени со 401.

Со AI градител опишете ја поставката прецизно:

Фронтенд-от на https://myapp.com го повикува API-то на https://api.myapp.com и добива „Response to preflight request doesn't pass access control check“. Конфигурирај CORS на API-то така што ќе дозволува точно https://myapp.com и origin-от на прегледот, да дозволува GET, POST, PATCH, DELETE со заглавијата Content-Type и Authorization, да ракува со OPTIONS пред автентикацијата, и да вклучи CORS заглавија и на одговорите со грешки.

Чекор 4: Ракувајте со колачиња и credentials

Ако вашиот фронтенд испраќа колачиња (на пример сесија за најава) до друг origin, двете страни мора да се согласат:

• Фронтенд-от поставува credentials: "include" на fetch, или withCredentials: true во axios.
• Серверот испраќа Access-Control-Allow-Credentials: true.
• Access-Control-Allow-Origin на серверот мора да биде точниот origin, а не *.

Меѓусајтовските колачиња исто така треба SameSite=None; Secure, а некои прелистувачи дополнително ги ограничуваат колачињата од трети страни. Тоа е уште една причина да го претпочитате пристапот од Чекор 5.

Чекор 5: Избегнете CORS со поставка на ист origin

Често најчистата поправка е да не правите меѓусајтовски барања воопшто. Послужете го API-то од истиот origin како страницата, на пример на https://myapp.com/api/...:

• Во развој, повеќето развојни сервери можат да прокси. Поставката server.proxy во Vite може да го препрати /api кон вашиот бекенд на друга порта, па прелистувачот секогаш комуницира само со еден origin.
• Во продукција, рутирајте го /api кон бекендот преку rewrite или proxy поставките на вашиот хост, или послужете го фронтендот и API-то од еден сервер.

Фронтендот тогаш повикува релативна патека како fetch("/api/orders"). Нема меѓусајтовско барање, нема preflight меѓу origin-и и нема проблеми со колачиња. Исто така, не ја кодирате API доменот што се разликува помеѓу прегледот и продукцијата.

Промени го фронтендот да го повикува бекендот со релативни /api патеки наместо целосен URL, и постави развоен прокси така што /api ќе се препраќа кон API серверот. Потоа отстрани ги CORS поставките што веќе не ни требаат.

Што да не правите

• mode: "no-cors" во fetch. Ништо не заобиколува; му дава на вашиот код празен, нечитлив одговор.
• Додатоци за прелистувач што го исклучуваат CORS. Тие ја менуваат само вашата прелистувач. Секој посетител сè уште ја гледа грешката.
• Јавни „CORS прокси“ услуги за вистински апликации. Можат да читаат и менуваат сè што минува низ нив, а и се расипуваат.
• Access-Control-Allow-Origin: * на API што користи најава. И онака не функционира со credentials, а е погрешен почетен избор за приватни податоци.
• Враќање на секој Origin заглавие назад со дозволени credentials. Тоа му овозможува на секоја веб-страница да прави барања со најава во име на вашите корисници. Користете список на дозволени.

Чести причини во апликации изградени со AI

CORS во Mythex

Кога проектот во Mythex има веб-сајт и API сервер, и двете работат како услуги во истиот проект, а можете да се префрлате меѓу нив во прегледот. Ако му кажете на агентот фронтендот да го повикува бекендот преку релативна /api патека, проксирана во развој, избегнувате повеќето CORS проблеми. Ако навистина ви требаат меѓусајтовски повици, дајте му на агентот точната грешка од конзолата и вклучените origin-и. Проверете го резултатот и на објавената апликација, бидејќи нејзината адреса се разликува од прегледот. Видете Повеќе-сервисни апликации и API бекенди во документацијата, и нашите водичи за дебагирање на апликација изградена со AI и фронтенд наспроти бекенд.

Контролна листа за CORS

• Прочитана целата грешка од конзолата и статус кодот на неуспешното барање
• Исклучена скриена 404 или 500 грешка
• API-ја со тајни клучеви се повикуваат од бекендот, не од прелистувачот
• Серверот испраќа Access-Control-Allow-Origin со точни дозволени origin-и
• OPTIONS preflight-от е одговорен со дозволени методи и заглавија, пред автентикацијата
• CORS заглавијата се присутни и на одговорите со грешки
• Credentials: точен origin, Allow-Credentials: true и точни поставки за колачиња
• Опфатени се прегледот, објавениот и прилагодениот домен, или се користат релативни /api патеки
• Нема no-cors, јавни проксија или враќање на секој origin

Прашања