Jinsi ya Kurekebisha Makosa ya CORS (na Kwa Nini Yanatokea)

Kosa la CORS linamaanisha ukurasa wako wa wavuti ulijaribu kusoma jibu kutoka asili tofauti (domeni, port au protokali nyingine), na server hiyo haikutuma header zinazosema inaruhusiwa. Vivinjari vinazuia jibu ili kuwalinda watumiaji. Unalirekebisha kwenye server, kwa kurudisha header ya Access-Control-Allow-Origin kwa asili ya tovuti yako na kushughulikia maombi ya OPTIONS ya preflight, au unaliepuka kwa kutuma ombi kupitia backend yako mwenyewe kwenye asili moja.

Ni moja ya makosa yanayochanganya zaidi kwenye ukuzaji wa wavuti kwa sababu ombi mara nyingi linamfikia server vizuri. Mwongozo huu unaeleza kinachoendelea na jinsi ya kurekebisha kila aina.

Maana ya "asili"

Asili (origin) ni mchanganyiko wa protokali, domeni na port:

Vivinjari vinafuata sera ya asili moja (same-origin policy): JavaScript ya ukurasa inaweza kusoma majibu kutoka asili yake yenyewe kwa uhuru, lakini si kutoka nyingine. CORS (Cross-Origin Resource Sharing) ni mfumo unaoruhusu server kujiunga kwa hiari: "majibu kutoka kwangu yanaweza kusomwa na kurasa kutoka asili hizi."

Mambo mawili yanawashangaza watu wengi:

• Ombi mara nyingi linamfikia server. CORS kwa kawaida inazuia msimbo wako kusoma jibu, si server kupokea ombi. POST inaweza kuwa imehifadhiwa hata ukiona hitilafu.
• Vivinjari pekee vinatekeleza. curl, Postman na msimbo wa upande wa server hupuuza CORS kabisa. Ndiyo maana "inafanya kazi kwenye Postman" haikuambii chochote kuhusu CORS.

Hatua ya 1: Soma hitilafu kamili

Fungua zana za msanidi (bonyeza kulia → Inspect), nenda kwenye Console, na usome ujumbe kamili. Maneno ya Chrome yanakuambia tatizo ni lipi:

Kisha fungua kichupo cha Network, tafuta ombi lililoshindwa (na ombi lolote la OPTIONS lililotangulia), na uangalie hali yake na header za jibu.

Angalia hali kwanza. Makosa mengi ya "CORS" kwa kweli ni hitilafu ya server iliyojificha. Server ikianguka au ikirudisha 404, jibu lake la hitilafu mara nyingi halina header za CORS, kwa hiyo kivinjari kinaripoti CORS badala ya tatizo halisi. Rekebisha 500 au 404, na kosa la CORS linaweza kutoweka.

Hatua ya 2: Amua kama unapaswa kuita API hiyo kutoka kivinjari kabisa

Kabla ya kuongeza header, jiulize: je, kivinjari kinapaswa kuita API hii moja kwa moja?

• API ya mtu wa tatu inayohitaji funguo ya siri (OpenAI, funguo ya siri ya Stripe, huduma nyingi za barua pepe) haipaswi kuitwa kutoka kivinjari kamwe. Funguo ingeonekana kwa kila mgeni. Iite kutoka backend yako, na tatizo la CORS linatoweka, kwa sababu maombi ya server-kwa-server hayako chini ya CORS. Tazama jinsi ya kulinda funguo za API.
• API ya mtu wa tatu usiyoidhibiti ambayo haituma header za CORS haiwezi kurekebishwa upande wako. Iite kutoka backend yako.
• API yako mwenyewe inaweza kurekebishwa kwa kuisanidi vizuri. Endelea hapa chini.

Hatua ya 3: Rekebisha kwenye server yako

Server lazima iongeze header sahihi kwenye majibu yake, ikiwemo majibu ya hitilafu.

Kwa ombi halisi, tuma:

• Access-Control-Allow-Origin: https://myapp.com (asili kamili ya frontend yako, bila slash ya mwisho)
• Vary: Origin, ikiwa thamani inategemea asili iliyoomba

Kwa ombi la preflight la OPTIONS, jibu kwa hali ya mafanikio (200 au 204) na:

• Access-Control-Allow-Origin: https://myapp.com
• Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE
• Access-Control-Allow-Headers: Content-Type, Authorization (kila header maalum unayotuma)
• Hiari Access-Control-Max-Age: 600, ili kivinjari kihifadhi preflight kwa muda

Frameworks nyingi zina package au mpangilio unaofanya hili. Kwenye Express, package ya cors; kwenye FastAPI, CORSMiddleware; kwenye ASP.NET Core, AddCors; kwenye Spring, @CrossOrigin au usanidi wa CORS. Mfano wa kawaida wa Express:

import cors from "cors";

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

Weka ushughulikiaji wa CORS kabla ya routes zako na uthibitishaji, ili maombi ya preflight (ambayo hayabebi kuingia) yasikataliwe kwa 401.

Kwa zana ya kujenga ya AI, eleza usanidi kwa usahihi:

Frontend kwenye https://myapp.com inaita API kwenye https://api.myapp.com na inapata "Response to preflight request doesn't pass access control check". Sanidi CORS kwenye API ili iruhusu https://myapp.com na asili ya preview tu, iruhusu GET, POST, PATCH, DELETE pamoja na header za Content-Type na Authorization, shughulikia OPTIONS kabla ya uthibitishaji, na jumuisha header za CORS hata kwenye majibu ya hitilafu.

Hatua ya 4: Shughulikia cookies na credentials

Ikiwa frontend yako inatuma cookies (kwa mfano kikao cha kuingia) kwenye asili nyingine, pande zote mbili lazima zikubaliane:

• Frontend inaweka credentials: "include" kwenye fetch, au withCredentials: true kwenye axios.
• Server inatuma Access-Control-Allow-Credentials: true.
• Access-Control-Allow-Origin ya server lazima iwe asili kamili, si *.

Cookies za kuvuka tovuti pia zinahitaji SameSite=None; Secure kwenye cookie, na vivinjari vingine vinazuia cookies za watu wa tatu zaidi. Hiyo ni sababu nyingine ya kupendelea njia ya Hatua ya 5.

Hatua ya 5: Epuka CORS kwa usanidi wa asili moja

Mara nyingi suluhisho safi zaidi ni kutofanya maombi ya vikoa tofauti kabisa. Tumia API kutoka asili ile ile ya ukurasa, kwa mfano https://myapp.com/api/...:

• Wakati wa maendeleo, seva nyingi za maendeleo zinaweza ku-proxy. server.proxy ya Vite inaweza kupeleka /api kwenye backend yako kwenye port nyingine, ili kivinjari kiwasiliane na asili moja tu.
• Kwenye uzalishaji, elekeza /api kwenye backend kupitia mipangilio ya rewrite au proxy ya host yako, au tumia server moja kwa frontend na API.

Kisha frontend inaita njia ya jamaa kama fetch("/api/orders"). Hakuna ombi la kuvuka vikoa, hakuna preflight kati ya asili, na hakuna shida za cookies. Pia inamaanisha hutaweka domeni ya API kwenye msimbo ambayo inatofautiana kati ya preview na uzalishaji.

Badilisha frontend iite backend kwa njia za jamaa za /api badala ya URL kamili, na weka proxy ya maendeleo ili /api ipeleke kwenye server ya API. Kisha ondoa mipangilio yoyote ya CORS ambayo hatuihitaji tena.

Usichopaswa kufanya

• mode: "no-cors" kwenye fetch. Haipiti kitu; inakupa jibu tupu lisilosomeka.
• Nyongeza za kivinjari zinazozima CORS. Zinabadilisha kivinjari chako pekee. Kila mgeni bado ataona kosa.
• Huduma za umma za "CORS proxy" kwa app halisi. Zinaweza kusoma na kubadilisha kila kitu kinachopitia kwao, na zinaanguka.
• Access-Control-Allow-Origin: * kwenye API inayotumia kuingia. Haifanyi kazi na credentials hata hivyo, na ni chaguo-msingi mbaya kwa data ya faragha.
• Kurudisha Origin yoyote iliyotumwa pamoja na kuruhusu credentials. Hiyo inaruhusu tovuti yoyote kufanya maombi yaliyoingia kwa niaba ya watumiaji wako. Tumia orodha ya ruhusa.

Sababu za kawaida kwenye app za AI

CORS kwenye Mythex

Mradi wa Mythex ukiwa na tovuti na server ya API, zote zinaendeshwa kama huduma kwenye mradi mmoja, na unaweza kubadilisha kati yao kwenye preview. Kumwomba wakala afanye frontend iite backend kupitia njia ya jamaa /api, iliyo proxy wakati wa maendeleo, huepusha matatizo mengi ya CORS. Ukihitaji wito wa kuvuka vikoa, mpe wakala kosa kamili kutoka console na asili zinazohusika. Kagua matokeo kwenye app iliyochapishwa pia, kwani anwani yake inatofautiana na preview. Tazama Huduma nyingi na Backends za API kwenye docs, pamoja na miongozo yetu ya kutatua app iliyojengwa kwa AI na frontend dhidi ya backend.

Orodha ya CORS

• Nimesoma kosa kamili la console na hali ya ombi lililoshindwa
• Nimekagua kama kuna 404 au 500 iliyojificha
• APIs zenye funguo za siri zinaitwa kutoka backend, si kivinjari
• Server inatuma Access-Control-Allow-Origin yenye asili kamili zinazoruhusiwa
• Preflight ya OPTIONS inajibiwa kwa methods na headers zinazoruhusiwa, kabla ya uthibitishaji
• Header za CORS zipo hata kwenye majibu ya hitilafu
• Credentials: asili kamili, Allow-Credentials: true, na mipangilio sahihi ya cookie
• Asili za preview, zilizochapishwa na domeni maalum zote zimejumuishwa, au njia za jamaa /api zinatumika
• Hakuna no-cors, proxies za umma, wala njia ya kurudisha asili yoyote

Maswali