የCORS ስህተቶችን እንዴት ማስተካከል (ለምን እንደሚፈጠሩ)

የCORS ስህተት ማለት የድር ገጽዎ ከሌላ ኦሪጅን (ሌላ ዶሜን፣ ፖርት ወይም ፕሮቶኮል) ምላሽ ለማንበብ ሞክሯል፣ እና ያ ሰርቨር መፍቀዱን የሚናገሩ ራስጌዎች አልላከም ማለት ነው። አሳሾች ተጠቃሚውን ለመጠበቅ ምላሹን ያግዳሉ። የሚስተካከለው በሰርቨሩ ላይ ነው፣ የገጻችሁን ኦሪጅን የሚመልስ Access-Control-Allow-Origin ራስጌ በመስጠትና OPTIONS preflight ጥያቄዎችን በማስተናገድ፣ ወይም ጥያቄውን በራሳችሁ ጀርባ በተመሳሳይ ኦሪጅን በመላክ ይቀራል።

በድር ልማት ውስጥ ከበጣም ግራ ከሚያጋቡ ስህተቶች አንዱ ነው፣ ምክንያቱም ጥያቄው ብዙ ጊዜ ሰርቨሩ ጋር በሰላም ይደርሳል። ይህ መመሪያ የሚሆነውን እና እያንዳንዱን ዓይነት እንዴት እንደሚስተካከል ያብራራል።

«ኦሪጅን» ማለት ምን ማለት ነው

ኦሪጅን የፕሮቶኮል፣ ዶሜን እና ፖርት ጥምረት ነው፦

አሳሾች ተመሳሳይ-ኦሪጅን ፖሊሲን ይከተላሉ፦ የገጽ JavaScript ከራሱ ኦሪጅን ምላሾችን በነፃነት ማንበብ ይችላል፣ ከሌሎች ግን አይችልም። CORS (Cross-Origin Resource Sharing) ሰርቨር በፈቃዱ የሚጠቀምበት ስርዓት ነው፦ «ከእኔ የሚመጡ ምላሾች ከእነዚህ ኦሪጅኖች ለሚመጡ ገጾች ይነበቡ።»

ሁለት ውጤቶች ሰዎችን ያስደንቃሉ፦

• ጥያቄው ብዙ ጊዜ ሰርቨሩ ይደርሳል። CORS ብዙ ጊዜ ኮዳችሁ ምላሹን እንዳያነብ ይከለክላል፣ ሰርቨሩ ጥያቄውን እንዳይቀበል አይደለም። POST ተቀምጦ ሊሆን ይችላል፣ ምንም እንኳን ስህተት ቢያዩም።
• አሳሾች ብቻ ያስፈጽሙታል። curl፣ Postman እና የሰርቨር-ጎን ኮድ CORSን ፈጽሞ አይከተሉም። ለዚህ ነው «በPostman ይሠራል» ስለ CORS ምንም የማይነግራችሁ።

ደረጃ 1፡ ትክክለኛውን ስህተት ያንብቡ

የገንቢ መሣሪያዎችን ይክፈቱ (ቀኝ-ጠቅ → Inspect)፣ ወደ Console ይሂዱ፣ እና ሙሉውን መልዕክት ያንብቡ። የChrome አጻጻፍ የትኛው ችግር እንዳለባችሁ ይነግራችኋል፦

ከዚያ Network ትሩን ይክፈቱ፣ የወደቀውን ጥያቄ (እና ከእሱ በፊት ያለ ማንኛውም OPTIONS ጥያቄ) ያግኙ፣ እና የሁኔታ ኮዱንና የምላሽ ራስጌዎቹን ይመልከቱ።

መጀመሪያ የሁኔታ ኮዱን ይፈትሹ። ብዙ «CORS ስህተቶች» በእውነቱ በመደበቂያ የሰርቨር ስህተት ናቸው። ሰርቨሩ ከተበላሸ ወይም 404 ከመለሰ፣ የስህተት ምላሹ ብዙ ጊዜ CORS ራስጌዎች ስለሌሉት አሳሹ ትክክለኛውን ችግር ሳይሆን CORS ይላል። 500ውን ወይም 404ውን መጀመሪያ ያስተካክሉ፤ CORS ስህተቱ ሊጠፋ ይችላል።

ደረጃ 2፡ ያንን ኤፒአይ ከአሳሹ መጥራት እንዳለባችሁ ወስኑ

ራስጌዎችን ከመጨመርዎ በፊት ጠይቁ፦ አሳሹ ይህን ኤፒአይ በቀጥታ መጥራት አለበት?

• ሚስጥራዊ ቁልፍ የሚያስፈልገው የሶስተኛ ወገን ኤፒአይ (OpenAI፣ Stripe ሚስጥራዊ ቁልፍ፣ አብዛኛዎቹ የኢሜይል አገልግሎቶች) ከአሳሹ መጠራት የለበትም። ቁልፉ ለእያንዳንዱ ጎብኚ ይታያል። ከጀርባዎ ይጥሩት፣ እና የCORS ችግሩ ይጠፋል፣ ምክንያቱም ሰርቨር-ወደ-ሰርቨር ጥያቄዎች በCORS አይገደቡም። ኤፒአይ ቁልፎችን እንዴት መጠበቅ ይመልከቱ።
• የማይቆጣጠሩት የሶስተኛ ወገን ኤፒአይ CORS ራስጌ የማይልክ ከሆነ ከጎንዎ አይስተካከልም። ከጀርባዎ ይጥሩት።
• የራስዎ ኤፒአይ በትክክል በማዋቀር ሊስተካከል ይችላል። ከታች ይቀጥሉ።

ደረጃ 3፡ በሰርቨርዎ ላይ ያስተካክሉ

ሰርቨሩ ትክክለኛዎቹን ራስጌዎች ለምላሾቹ፣ የስህተት ምላሾችንም ጨምሮ፣ መጨመር አለበት።

ለዋናው ጥያቄ ይላኩ፦

• Access-Control-Allow-Origin: https://myapp.com (የፊት-ለፊትዎ ትክክለኛ ኦሪጅን፣ የመጨረሻ ሰረዝ የሌለው)
• Vary: 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 ላይ ነው፣ ኤፒአይው https://api.myapp.com ላይ ነው፣ እና «Response to preflight request doesn't pass access control check» ይቀበላል። በኤፒአይው ላይ CORSን ልክ https://myapp.com እና የቅድመ-እይታ ኦሪጅኑን እንዲፈቅድ አዋቅር፣ GET፣ POST፣ PATCH፣ DELETE ከContent-Type እና Authorization ራስጌዎች ጋር ፍቀድ፣ OPTIONSን ከማረጋገጫ በፊት ያዝ፣ እና CORS ራስጌዎች በስህተት ምላሾች ላይም ይገኙ።

ደረጃ 4፡ ኩኪዎችንና ምስክርነቶችን ያዙ

ፊት-ለፊትዎ (ለምሳሌ የመግቢያ ክፍለ-ጊዜ) ኩኪዎችን ወደ ሌላ ኦሪጅን ከላከ፣ ሁለቱም ወገኖች መስማማት አለባቸው፦

• ፊት-ለፊቱ በfetch ላይ credentials: "include"፣ ወይም በaxios withCredentials: true ያዘጋጃል።
• ሰርቨሩ Access-Control-Allow-Credentials: true ይልካል።
• የሰርቨሩ Access-Control-Allow-Origin ትክክለኛው ኦሪጅን መሆን አለበት፣ * አይደለም።

የተሻገሩ-ጣቢያ ኩኪዎች በኩኪው ላይ SameSite=None; Secure ያስፈልጋቸዋል፣ አንዳንድ አሳሾችም የሶስተኛ ወገን ኩኪዎችን ተጨማሪ ይገድባሉ። ይህ ደግሞ በደረጃ 5 ያለውን አቀራረብ እንድትመርጡ ሌላ ምክንያት ነው።

ደረጃ 5፡ በተመሳሳይ-ኦሪጅን ማዋቀር CORSን ያስወግዱ

ብዙ ጊዜ ንፁህ መፍትሔው ምንም የተሻገሩ ጥያቄዎችን አለማድረግ ነው። ኤፒአይውን ከገጹ ተመሳሳይ ኦሪጅን ያቅርቡ፣ ለምሳሌ https://myapp.com/api/...፦

• በእድገት ጊዜ አብዛኞቹ የእድገት ሰርቨሮች ፕሮክሲ ማድረግ ይችላሉ። የVite server.proxy ቅንብር /apiን ወደ ጀርባዎ በሌላ ፖርት ሊያስተላልፍ ይችላል፣ ስለዚህ አሳሹ ከአንድ ኦሪጅን ብቻ ይነጋገራል።
• በምርት ላይ /apiን በማስተናገጃዎ rewrite ወይም ፕሮክሲ ቅንብሮች ወደ ጀርባው ይምሩ፣ ወይም ፊት-ለፊቱንና ኤፒአይውን ከአንድ ሰርቨር ያቅርቡ።

ፊት-ለፊቱ ከዚያ አንጻራዊ መንገድ ይጠራል፣ ለምሳሌ fetch("/api/orders")። የተሻገረ ጥያቄ የለም፣ በኦሪጅኖች መካከል preflight የለም፣ የኩኪ ራስ ምታትም የለም። በቅድመ-እይታና በምርት መካከል የሚለያይ የኤፒአይ ዶሜን በኮዱ ውስጥ መጻፍ አይጠበቅብዎትም።

የፊት-ለፊቱን ወደ ጀርባ ጥሪዎች ከሙሉ URL ይልቅ አንጻራዊ /api መንገዶችን እንዲጠቀም ቀይር፣ እና /api ወደ ኤፒአይ ሰርቨር እንዲተላለፍ የእድገት ፕሮክሲ አዘጋጅ። ከዚያ የማንፈልጋቸውን CORS ቅንብሮች አስወግድ።

ምን አታድርጉ

• mode: "no-cors" በfetch። ምንም አያልፍም፤ ኮዳችሁ ባዶ፣ የማይነበብ ምላሽ ብቻ ያገኛል።
• CORSን የሚያጠፉ የአሳሽ ተጨማሪዎች። የእናንተን አሳሽ ብቻ ይቀይራሉ። እያንዳንዱ ጎብኚ አሁንም ስህተቱን ያያል።
• ለእውነተኛ መተግበሪያዎች የህዝብ «CORS ፕሮክሲ» አገልግሎቶች። በእነሱ የሚያልፍን ሁሉ ማንበብና መቀየር ይችላሉ፣ እንዲሁም ይወድቃሉ።
• በመግቢያ ላይ ለሚመሰረት ኤፒአይ Access-Control-Allow-Origin: *። ከምስክርነቶች ጋር በጭራሽ አይሠራም፣ ለግል ውሂብም የተሳሳተ ነባሪ ነው።
• ማንኛውንም Origin ራስጌ ወደ ኋላ መመለስና ምስክርነቶች መፍቀድ። ማንኛውም ድረ-ገጽ በተጠቃሚዎቻችሁ ስም ከመግቢያ ጋር ጥያቄዎችን እንዲያደርግ ይፈቅዳል። የተፈቀዱ ዝርዝር ይጠቀሙ።

በ AI የተገነቡ መተግበሪያዎች ውስጥ የተለመዱ መንስኤዎች

CORS በ Mythex

የ Mythex ፕሮጀክት ድረ-ገጽና ኤፒአይ ሰርቨር ሲኖረው ሁለቱም በአንድ ፕሮጀክት ውስጥ እንደ አገልግሎቶች ይሠራሉ፣ እና በቅድመ-እይታው ውስጥ ሊቀያየሩ ይችላሉ። ፊት-ለፊቱ ጀርባውን በአንጻራዊ /api መንገድ እንዲጠራ፣ በእድገት ጊዜ ፕሮክሲ እንዲደረግ ለወኪሉ መጠየቅ አብዛኞቹን የCORS ችግሮች ያስወግዳል። የተሻገሩ ጥሪዎች የግድ ካስፈለጉ ከኮንሶሉ ትክክለኛውን ስህተትና የሚሳተፉትን ኦሪጅኖች ለወኪሉ ይስጡ። የታተመው መተግበሪያ አድራሻው ከቅድመ-እይታው ስለሚለይ ውጤቱን በእሱም ላይ ያረጋግጡ። በሰነዶቹ ባለብዙ-አገልግሎት መተግበሪያዎች እና ኤፒአይ ጀርባዎች ይመልከቱ፣ እና የየ AI የተገነባ መተግበሪያን ማረም እና frontend ከ backend መመሪያዎቻችንን ይመልከቱ።

የCORS ማረጋገጫ ዝርዝር

• ሙሉውን የኮንሶል ስህተትና የወደቀው ጥያቄ የሁኔታ ኮድ አንብቧል
• የተደበቀ 404 ወይም 500 መኖሩ ተወግዷል
• ሚስጥራዊ ቁልፍ ያላቸው ኤፒአይዎች ከአሳሹ ሳይሆን ከጀርባ ይጠራሉ
• ሰርቨሩ ትክክለኛ የተፈቀዱ ኦሪጅኖች ያሉት Access-Control-Allow-Origin ይልካል
• የOPTIONS preflight ከማረጋገጫ በፊት በተፈቀዱ ዘዴዎችና ራስጌዎች ተመልሷል
• በስህተት ምላሾች ላይም የCORS ራስጌዎች አሉ
• ምስክርነቶች፦ ትክክለኛ ኦሪጅን፣ Allow-Credentials: true እና ትክክለኛ የኩኪ ቅንብሮች
• ቅድመ-እይታ፣ የታተመና ብጁ-ዶሜን ኦሪጅኖች ሁሉም ተሸፍነዋል፣ ወይም አንጻራዊ /api መንገዶች ተጠቅመዋል
• no-cors፣ የህዝብ ፕሮክሲዎችና ማንኛውንም-ኦሪጅን-ማንጸባረቅ አቋራጮች የሉም

ጥያቄዎች