CORS ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸುವುದು ಹೇಗೆ (ಮತ್ತು ಅವು ಏಕೆ ಬರುತ್ತವೆ)

CORS error ಎಂದರೆ ನಿಮ್ಮ ವೆಬ್ ಪುಟ ಬೇರೆ ಆರಿಜಿನ್‌ನಿಂದ (ಬೇರೆ ಡೊಮೇನ್, ಪೋರ್ಟ್ ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್) ಪ್ರತಿಕ್ರಿಯೆ ಓದಲು ಪ್ರಯತ್ನಿಸಿದೆ, ಆದರೆ ಆ ಸರ್ವರ್ ಅದನ್ನು ಅನುಮತಿಸುವ ಹೆಡರ್‌ಗಳನ್ನು ಕಳುಹಿಸಿಲ್ಲ ಎಂದರ್ಥ. ಬ್ರೌಸರ್‌ಗಳು ಬಳಕೆದಾರರನ್ನು ರಕ್ಷಿಸಲು ಆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ತಡೆಯುತ್ತವೆ. ಇದನ್ನು ಸರಿಪಡಿಸುವ ಮಾರ್ಗ ಸರ್ವರ್‌ನಲ್ಲಿ: ನಿಮ್ಮ ಸೈಟ್‌ನ ಆರಿಜಿನ್‌ಗಾಗಿ Access-Control-Allow-Origin ಹೆಡರ್ ಹಿಂತಿರುಗಿಸುವುದು ಮತ್ತು OPTIONS ಪ್ರಿಫ್ಲೈಟ್ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು. ಅಥವಾ ವಿನಂತಿಯನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಬ್ಯಾಕೆಂಡ್ ಮೂಲಕ, ಅದೇ ಆರಿಜಿನ್‌ನಲ್ಲಿ ಕಳುಹಿಸಿ ತಪ್ಪಿಸಬಹುದು.

ಇದು ವೆಬ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಅತ್ಯಂತ ಗೊಂದಲಕಾರಿ ದೋಷಗಳಲ್ಲಿ ಒಂದು, ಏಕೆಂದರೆ ವಿನಂತಿ ಸಾಮಾನ್ಯವಾಗಿ ಸರ್ವರ್ ತಲುಪುತ್ತದೆ. ಈ ಮಾರ್ಗದರ್ಶಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಮತ್ತು ಪ್ರತಿ ರೂಪಾಂತರವನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸುವುದು ಎಂದು ವಿವರಿಸುತ್ತದೆ.

"ಆರಿಜಿನ್" ಎಂದರೆ ಏನು

ಆರಿಜಿನ್ ಎಂದರೆ ಪ್ರೋಟೋಕಾಲ್, ಡೊಮೇನ್ ಮತ್ತು ಪೋರ್ಟ್‌ನ ಸಂಯೋಜನೆ:

URL	ಆರಿಜಿನ್
`https://myapp.com/dashboard`	`https://myapp.com`
`https://api.myapp.com/users`	`https://api.myapp.com` (ಬೇರೆ ಸಬ್‌ಡೊಮೇನ್, ಆದ್ದರಿಂದ ಬೇರೆ ಆರಿಜಿನ್)
`http://localhost:5173`	`http://localhost:5173`
`http://localhost:3000`	`http://localhost:3000` (ಬೇರೆ ಪೋರ್ಟ್, ಆದ್ದರಿಂದ ಬೇರೆ ಆರಿಜಿನ್)

ಬ್ರೌಸರ್‌ಗಳು same-origin policy ಅನುಸರಿಸುತ್ತವೆ: ಒಂದು ಪುಟದ JavaScript ತನ್ನ ಸ್ವಂತ ಆರಿಜಿನ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಮುಕ್ತವಾಗಿ ಓದಬಹುದು, ಆದರೆ ಬೇರೆಯವುಗಳಿಂದ ಅಲ್ಲ. CORS (Cross-Origin Resource Sharing) ಎಂಬುದು ಸರ್ವರ್ ಒಪ್ಪಿಗೆ ನೀಡುವ ವ್ಯವಸ್ಥೆ: "ಈ ಆರಿಜಿನ್‌ಗಳ ಪುಟಗಳು ನನ್ನ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಓದಬಹುದು."

ಜನರನ್ನು ಅಚ್ಚರಿಗೊಳಿಸುವ ಎರಡು ಪರಿಣಾಮಗಳು:

ವಿನಂತಿ ಸಾಮಾನ್ಯವಾಗಿ ಸರ್ವರ್ ತಲುಪುತ್ತದೆ. CORS ಸಾಮಾನ್ಯವಾಗಿ ನಿಮ್ಮ ಕೋಡ್ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಓದುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಸರ್ವರ್ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನಲ್ಲ. ದೋಷ ಕಂಡರೂ POST ಉಳಿಸಲ್ಪಟ್ಟಿರಬಹುದು.
ಬ್ರೌಸರ್‌ಗಳು ಮಾತ್ರ ಇದನ್ನು ಜಾರಿಗೊಳಿಸುತ್ತವೆ. curl, Postman ಮತ್ತು ಸರ್ವರ್-ಬದಿ ಕೋಡ್ CORS ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ. ಆದ್ದರಿಂದ "Postman ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ" ಎಂಬುದು CORS ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಹಂತ 1: ನಿಖರ ದೋಷವನ್ನು ಓದಿ

ಡೆವಲಪರ್ ಟೂಲ್‌ಗಳನ್ನು ತೆರೆಯಿರಿ (ರೈಟ್-ಕ್ಲಿಕ್ → Inspect), Console ಟ್ಯಾಬ್‌ಗೆ ಹೋಗಿ, ಪೂರ್ಣ ಸಂದೇಶವನ್ನು ಓದಿ. Chrome ನ ಪದಗಳು ನಿಮಗೆ ಯಾವ ಸಮಸ್ಯೆ ಇದೆ ಎಂದು ತಿಳಿಸುತ್ತವೆ:

ಸಂದೇಶದಲ್ಲಿ ಇರುವುದು	ತಪ್ಪು ಏನು
`No 'Access-Control-Allow-Origin' header is present`	ಸರ್ವರ್ ಆ ಹೆಡರ್ ಕಳುಹಿಸಿಲ್ಲ, ಅಥವಾ ವಿನಂತಿ ನಿಮ್ಮ CORS ಕೋಡ್ ತಲುಪುವ ಮೊದಲೇ ವಿಫಲವಾಗಿದೆ (ಉದಾ. 404 ಅಥವಾ 500)
`The 'Access-Control-Allow-Origin' header has a value '...' that is not equal to the supplied origin`	ಸರ್ವರ್ ನಿಮ್ಮದಲ್ಲದ ಬೇರೆ ಆರಿಜಿನ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತಿದೆ
`Response to preflight request doesn't pass access control check`	`OPTIONS` ಪ್ರಿಫ್ಲೈಟ್ ವಿಫಲವಾಗಿದೆ
`...must not be the wildcard '*' when the request's credentials mode is 'include'`	ನೀವು ಕುಕೀಗಳನ್ನು ಕಳುಹಿಸುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ಸರ್ವರ್ `*` ಉತ್ತರಿಸಿದೆ
`Request header field authorization is not allowed`	ಸರ್ವರ್ `Access-Control-Allow-Headers` ನಲ್ಲಿ ಆ ಹೆಡರ್ ಅನ್ನು ಪಟ್ಟಿ ಮಾಡಿಲ್ಲ

ನಂತರ Network ಟ್ಯಾಬ್ ತೆರೆಯಿರಿ, ವಿಫಲವಾದ ವಿನಂತಿಯನ್ನು (ಮತ್ತು ಅದಕ್ಕೆ ಮುಂಚಿನ ಯಾವುದೇ OPTIONS ವಿನಂತಿಯನ್ನು) ಹುಡುಕಿ, ಅದರ ಸ್ಥಿತಿ ಕೋಡ್ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಹೆಡರ್‌ಗಳನ್ನು ನೋಡಿ.

ಮೊದಲು ಸ್ಥಿತಿ ಕೋಡ್ ನೋಡಿ. ಹಲವು "CORS ದೋಷಗಳು" ನಿಜವಾಗಿ ವೇಷ ಧರಿಸಿದ ಸರ್ವರ್ ದೋಷಗಳು. ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆದರೆ ಅಥವಾ 404 ನೀಡಿದರೆ, ಅದರ ದೋಷ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ CORS ಹೆಡರ್‌ಗಳು ಇರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಬ್ರೌಸರ್ ನಿಜವಾದ ಸಮಸ್ಯೆಯ ಬದಲು CORS ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. 500 ಅನ್ನು ಸರಿಪಡಿಸಿ, CORS ದೋಷ ಮಾಯವಾಗಬಹುದು.

ಹಂತ 2: ಆ API ಅನ್ನು ಬ್ರೌಸರ್‌ನಿಂದ ಕರೆಯಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸಿ

ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಕೇಳಿಕೊಳ್ಳಿ: ಬ್ರೌಸರ್ ಈ API ಅನ್ನು ನೇರವಾಗಿ ಕರೆಯಬೇಕೇ?

ರಹಸ್ಯ ಕೀ ಬೇಕಾದ ಮೂರನೇ ಪಕ್ಷದ API (OpenAI, Stripe ರಹಸ್ಯ ಕೀ, ಹೆಚ್ಚಿನ ಇಮೇಲ್ ಸೇವೆಗಳು) ಬ್ರೌಸರ್‌ನಿಂದ ಎಂದಿಗೂ ಕರೆಯಬಾರದು. ಕೀ ಪ್ರತಿ ಸಂದರ್ಶಕರಿಗೆ ಗೋಚರಿಸುತ್ತದೆ. ಬದಲಿಗೆ ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ನಿಂದ ಕರೆಯಿರಿ; ಆಗ CORS ಸಮಸ್ಯೆ ಮಾಯವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಸರ್ವರ್‌ನಿಂದ ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಗಳು CORS ಗೆ ಒಳಪಡುವುದಿಲ್ಲ. API ಕೀಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಇಡುವುದು ಹೇಗೆ ನೋಡಿ.
ನೀವು ನಿಯಂತ್ರಿಸದ ಮೂರನೇ ಪಕ್ಷದ API CORS ಹೆಡರ್‌ಗಳನ್ನು ಕಳುಹಿಸದಿದ್ದರೆ, ನಿಮ್ಮ ಕಡೆಯಿಂದ ಸರಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ನಿಂದ ಕರೆಯಿರಿ.
ನಿಮ್ಮ ಸ್ವಂತ API ಅನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಮೂಲಕ ಸರಿಪಡಿಸಬಹುದು. ಮುಂದೆ ಮುಂದುವರಿಯಿರಿ.

ಹಂತ 3: ನಿಮ್ಮ ಸರ್ವರ್‌ನಲ್ಲಿ ಸರಿಪಡಿಸಿ

ಸರ್ವರ್ ತನ್ನ ಪ್ರತಿಕ್ರಿಯೆಗಳಿಗೆ ಸರಿಯಾದ ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸಬೇಕು, ದೋಷ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನೂ ಸೇರಿ.

ನಿಜವಾದ ವಿನಂತಿಗೆ ಕಳುಹಿಸಿ:

Access-Control-Allow-Origin: https://myapp.com (ನಿಮ್ಮ ಫ್ರಂಟ್‌ಎಂಡ್‌ನ ನಿಖರ ಆರಿಜಿನ್, ಕೊನೆಯಲ್ಲಿ ಸ್ಲ್ಯಾಷ್ ಇಲ್ಲದೆ)
Vary: Origin, ಮೌಲ್ಯ ಯಾವ ಆರಿಜಿನ್ ಕೇಳಿದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದ್ದರೆ

ಪ್ರಿಫ್ಲೈಟ್ 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, ಆಗ ಬ್ರೌಸರ್ ಪ್ರಿಫ್ಲೈಟ್ ಅನ್ನು ಸ್ವಲ್ಪ ಕಾಲ ಸಂಗ್ರಹಿಸುತ್ತದೆ

ಹೆಚ್ಚಿನ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಿಗೆ ಇದನ್ನು ಮಾಡುವ ಪ್ಯಾಕೇಜ್ ಅಥವಾ ಸೆಟ್ಟಿಂಗ್ ಇರುತ್ತದೆ. 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 ನಿರ್ವಹಣೆಯನ್ನು ರೂಟ್‌ಗಳು ಮತ್ತು ದೃಢೀಕರಣಕ್ಕಿಂತ ಮೊದಲು ಇಡಿ, ಇದರಿಂದ ಪ್ರಿಫ್ಲೈಟ್ ವಿನಂತಿಗಳು (ಲಾಗಿನ್ ಹೊತ್ತಿರುವುದಿಲ್ಲ) 401 ನಿಂದ ತಿರಸ್ಕೃತವಾಗುವುದಿಲ್ಲ.

AI ಬಿಲ್ಡರ್ ಬಳಸುತ್ತಿದ್ದರೆ, ಸೆಟಪ್ ಅನ್ನು ನಿಖರವಾಗಿ ವಿವರಿಸಿ:

https://myapp.com ನಲ್ಲಿರುವ ಫ್ರಂಟ್‌ಎಂಡ್ https://api.myapp.com ನಲ್ಲಿರುವ API ಅನ್ನು ಕರೆಯುತ್ತದೆ ಮತ್ತು "Response to preflight request doesn't pass access control check" ಪಡೆಯುತ್ತದೆ. API ನಲ್ಲಿ CORS ಅನ್ನು ನಿಖರವಾಗಿ https://myapp.com ಮತ್ತು ಪ್ರಿವ್ಯೂ ಆರಿಜಿನ್ ಅನ್ನು ಅನುಮತಿಸುವಂತೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಿ, Content-Type ಮತ್ತು Authorization ಹೆಡರ್‌ಗಳೊಂದಿಗೆ GET, POST, PATCH, DELETE ಅನ್ನು ಅನುಮತಿಸಿ, OPTIONS ಅನ್ನು ದೃಢೀಕರಣಕ್ಕಿಂತ ಮುಂಚೆ ನಿರ್ವಹಿಸಿ, ಮತ್ತು ದೋಷ ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿಯೂ CORS ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸಿ.

ಹಂತ 4: ಕುಕೀಗಳು ಮತ್ತು ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಿ

ನಿಮ್ಮ ಫ್ರಂಟ್‌ಎಂಡ್ ಬೇರೆ ಆರಿಜಿನ್‌ಗೆ ಕುಕೀಗಳನ್ನು (ಉದಾ. ಲಾಗಿನ್ ಸೆಷನ್) ಕಳುಹಿಸಿದರೆ, ಎರಡೂ ಬದಿಗಳು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು:

ಫ್ರಂಟ್‌ಎಂಡ್ fetch ನಲ್ಲಿ credentials: "include" ಅಥವಾ axios ನಲ್ಲಿ withCredentials: true ಹೊಂದಿಸುತ್ತದೆ.
ಸರ್ವರ್ Access-Control-Allow-Credentials: true ಕಳುಹಿಸುತ್ತದೆ.
ಸರ್ವರ್‌ನ Access-Control-Allow-Origin ನಿಖರ ಆರಿಜಿನ್ ಆಗಿರಬೇಕು, * ಅಲ್ಲ.

ಕ್ರಾಸ್-ಸೈಟ್ ಕುಕೀಗಳಿಗೆ ಕುಕೀಯಲ್ಲಿ SameSite=None; Secure ಬೇಕು, ಮತ್ತು ಕೆಲವು ಬ್ರೌಸರ್‌ಗಳು ಮೂರನೇ ಪಕ್ಷದ ಕುಕೀಗಳನ್ನು ಇನ್ನಷ್ಟು ಮಿತಿಗೊಳಿಸುತ್ತವೆ. ಹಂತ 5 ರ ವಿಧಾನವನ್ನು ಆದ್ಯತೆ ನೀಡಲು ಇದೂ ಒಂದು ಕಾರಣ.

ಹಂತ 5: ಒಂದೇ ಆರಿಜಿನ್ ಸೆಟಪ್ ಬಳಸಿ CORS ತಪ್ಪಿಸಿ

ಹೆಚ್ಚಾಗಿ ಸ್ವಚ್ಛ ಪರಿಹಾರವೆಂದರೆ ಕ್ರಾಸ್-ಆರಿಜಿನ್ ವಿನಂತಿಗಳನ್ನೇ ಮಾಡದಿರುವುದು. API ಅನ್ನು ಪುಟದ ಅದೇ ಆರಿಜಿನ್‌ನಲ್ಲಿ ಸರ್ವ್ ಮಾಡಿ, ಉದಾಹರಣೆಗೆ https://myapp.com/api/... ನಲ್ಲಿ:

ಡೆವಲಪ್‌ಮೆಂಟ್‌ನಲ್ಲಿ, ಹೆಚ್ಚಿನ ಡೆವ್ ಸರ್ವರ್‌ಗಳು ಪ್ರಾಕ್ಸಿ ಮಾಡಬಲ್ಲವು. Vite ನ server.proxy ಸೆಟ್ಟಿಂಗ್ /api ಅನ್ನು ಬೇರೆ ಪೋರ್ಟ್‌ನಲ್ಲಿರುವ ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಬಹುದು, ಆಗ ಬ್ರೌಸರ್ ಒಂದೇ ಆರಿಜಿನ್‌ನೊಂದಿಗೆ ಮಾತ್ರ ಮಾತನಾಡುತ್ತದೆ.
ಪ್ರೊಡಕ್ಷನ್‌ನಲ್ಲಿ, ನಿಮ್ಮ ಹೋಸ್ಟ್‌ನ ರೀರೈಟ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಮೂಲಕ /api ಅನ್ನು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ರೂಟ್ ಮಾಡಿ, ಅಥವಾ ಫ್ರಂಟ್‌ಎಂಡ್ ಮತ್ತು API ಅನ್ನು ಒಂದೇ ಸರ್ವರ್‌ನಿಂದ ಸರ್ವ್ ಮಾಡಿ.

ಆಗ ಫ್ರಂಟ್‌ಎಂಡ್ fetch("/api/orders") ನಂತಹ ಸಾಪೇಕ್ಷ ಮಾರ್ಗವನ್ನು ಕರೆಯುತ್ತದೆ. ಕ್ರಾಸ್-ಆರಿಜಿನ್ ವಿನಂತಿ ಇಲ್ಲ, ಆರಿಜಿನ್‌ಗಳ ನಡುವಿನ ಪ್ರಿಫ್ಲೈಟ್ ಇಲ್ಲ, ಮತ್ತು ಕುಕೀ ತೊಂದರೆಗಳಿಲ್ಲ. ಪ್ರಿವ್ಯೂ ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ ನಡುವೆ ಬದಲಾಗುವ API ಡೊಮೇನ್ ಅನ್ನು ನೀವು ಕೋಡ್‌ನಲ್ಲಿ ಹಾರ್ಡ್-ಕೋಡ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ ಎಂದೂ ಇದರ ಅರ್ಥ.

ಫ್ರಂಟ್‌ಎಂಡ್ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಪೂರ್ಣ URL ಬದಲು ಸಾಪೇಕ್ಷ /api ಮಾರ್ಗಗಳ ಮೂಲಕ ಕರೆಯುವಂತೆ ಬದಲಾಯಿಸಿ, ಮತ್ತು /api ಅನ್ನು API ಸರ್ವರ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಡೆವ್ ಪ್ರಾಕ್ಸಿ ಹೊಂದಿಸಿ. ನಂತರ ನಮಗೆ ಇನ್ನು ಅಗತ್ಯವಿಲ್ಲದ ಯಾವುದೇ CORS ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕಿ.

ತಪ್ಪಿಸಬೇಕಾದ ವಿಷಯಗಳು

fetch ನಲ್ಲಿ mode: "no-cors". ಇದು ಯಾವುದನ್ನೂ ಬೈಪಾಸ್ ಮಾಡುವುದಿಲ್ಲ; ಇದು ನಿಮ್ಮ ಕೋಡ್‌ಗೆ ಖಾಲಿ, ಓದಲಾಗದ ಪ್ರತಿಕ್ರಿಯೆ ನೀಡುತ್ತದೆ.
CORS ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಬ್ರೌಸರ್ ವಿಸ್ತರಣೆಗಳು. ಅವು ನಿಮ್ಮ ಬ್ರೌಸರ್ ಅನ್ನು ಮಾತ್ರ ಬದಲಿಸುತ್ತವೆ. ಪ್ರತಿ ಸಂದರ್ಶಕರಿಗೂ ದೋಷ ಕಾಣಿಸುತ್ತದೆ.
ನಿಜವಾದ ಆಪ್‌ಗಳಿಗೆ ಸಾರ್ವಜನಿಕ "CORS ಪ್ರಾಕ್ಸಿ" ಸೇವೆಗಳು. ಅವುಗಳ ಮೂಲಕ ಹಾದುಹೋಗುವ ಎಲ್ಲವನ್ನೂ ಅವು ಓದಬಹುದು ಮತ್ತು ಬದಲಿಸಬಹುದು, ಮತ್ತು ಅವು ಕೆಳಗೆ ಹೋಗುತ್ತವೆ.
ಲಾಗಿನ್ ಇರುವ API ಯಲ್ಲಿ Access-Control-Allow-Origin: *. ಅದು ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಖಾಸಗಿ ಡೇಟಾಗೆ ಇದು ತಪ್ಪಾದ ಡೀಫಾಲ್ಟ್.
ಯಾವುದೇ Origin ಹೆಡರ್ ಅನ್ನು ಹಿಂದಕ್ಕೆ ಪ್ರತಿಫಲಿಸುವುದು ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು ಅನುಮತಿಸಿದಾಗ. ಇದರಿಂದ ಯಾವುದೇ ವೆಬ್‌ಸೈಟ್ ನಿಮ್ಮ ಬಳಕೆದಾರರ ಪರವಾಗಿ ಲಾಗಿನ್ ಆದ ವಿನಂತಿಗಳನ್ನು ಮಾಡಬಹುದು. ಅನುಮತಿ ಪಟ್ಟಿ (allowlist) ಬಳಸಿ.

AI ನಿರ್ಮಿತ ಆಪ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ಕಾರಣಗಳು

ಸ್ಥಿತಿ	ಪರಿಹಾರ
ಫ್ರಂಟ್‌ಎಂಡ್ ರಹಸ್ಯ ಕೀ ಇರುವ ಮೂರನೇ ಪಕ್ಷದ API ಅನ್ನು ಕರೆಯುತ್ತದೆ	ಕರೆಯನ್ನು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಸ್ಥಳಾಂತರಿಸಿ
ಪ್ರಿವ್ಯೂನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಪ್ರಕಟಿತ ಡೊಮೇನ್‌ನಲ್ಲಿ ವಿಫಲ	ಪ್ರಕಟಿತ ಮತ್ತು ಕಸ್ಟಮ್ ಡೊಮೇನ್ ಆರಿಜಿನ್‌ಗಳನ್ನು ಅನುಮತಿ ಪಟ್ಟಿಗೆ ಸೇರಿಸಿ, ಅಥವಾ ಸಾಪೇಕ್ಷ `/api` ಮಾರ್ಗಗಳನ್ನು ಬಳಸಿ
ದೋಷ ಕೇವಲ POST, PUT ಅಥವಾ DELETE ನಲ್ಲಿ	ಪ್ರಿಫ್ಲೈಟ್ ನಿರ್ವಹಿಸಲಾಗಿಲ್ಲ; `OPTIONS` ನಿರ್ವಹಣೆ ಮತ್ತು ಅನುಮತಿಸಿದ ಹೆಡರ್‌ಗಳನ್ನು ಸೇರಿಸಿ
ಲಾಗಿನ್ ಸೇರಿಸಿದ ನಂತರ ದೋಷ ಕಾಣಿಸಿದೆ	ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳಿಗೆ ನಿಖರ ಆರಿಜಿನ್ ಮತ್ತು `Allow-Credentials` ಬೇಕು
"CORS error" ಆದರೆ Network ಟ್ಯಾಬ್‌ನಲ್ಲಿ 500	ಮೊದಲು ಸರ್ವರ್ ದೋಷವನ್ನು ಸರಿಪಡಿಸಿ
API URL `localhost` ಗೆ ಹಾರ್ಡ್-ಕೋಡ್ ಆಗಿದೆ	ಸಾಪೇಕ್ಷ ಮಾರ್ಗಗಳು ಅಥವಾ ಪ್ರತಿ ಪರಿಸರಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಸೆಟ್ಟಿಂಗ್ ಬಳಸಿ

Mythex ನಲ್ಲಿ CORS

Mythex ಯೋಜನೆಯಲ್ಲಿ ವೆಬ್‌ಸೈಟ್ ಮತ್ತು API ಸರ್ವರ್ ಇದ್ದಾಗ, ಎರಡೂ ಒಂದೇ ಯೋಜನೆಯಲ್ಲಿ ಸೇವೆಗಳಾಗಿ ಚಲಿಸುತ್ತವೆ, ಮತ್ತು ಪ್ರಿವ್ಯೂನಲ್ಲಿ ನೀವು ಅವುಗಳ ನಡುವೆ ಬದಲಾಯಿಸಬಹುದು. ಫ್ರಂಟ್‌ಎಂಡ್ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಸಾಪೇಕ್ಷ /api ಮಾರ್ಗದ ಮೂಲಕ ಕರೆಯಬೇಕು, ಡೆವಲಪ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಮಾಡಬೇಕು ಎಂದು ಏಜೆಂಟ್‌ಗೆ ಕೇಳುವುದು ಹೆಚ್ಚಿನ CORS ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ನಿಮಗೆ ಕ್ರಾಸ್-ಆರಿಜಿನ್ ಕರೆಗಳು ಬೇಕಿದ್ದರೆ, ಕನ್ಸೋಲ್‌ನಲ್ಲಿರುವ ನಿಖರ ದೋಷ ಮತ್ತು ಒಳಗೊಂಡಿರುವ ಆರಿಜಿನ್‌ಗಳನ್ನು ಏಜೆಂಟ್‌ಗೆ ನೀಡಿ. ಪ್ರಕಟಿತ ಆಪ್‌ನಲ್ಲಿಯೂ ಫಲಿತಾಂಶವನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಅದರ ವಿಳಾಸ ಪ್ರಿವ್ಯೂಗಿಂತ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಡಾಕ್ಸ್‌ನಲ್ಲಿ ಮಲ್ಟಿ-ಸೇವೆ ಆಪ್‌ಗಳು ಮತ್ತು API ಬ್ಯಾಕೆಂಡ್‌ಗಳು ನೋಡಿ, ಮತ್ತು ನಮ್ಮ ಮಾರ್ಗದರ್ಶಿಗಳಲ್ಲಿ AI ನಿರ್ಮಿತ ಆಪ್ ಅನ್ನು ಡೀಬಗ್ ಮಾಡುವುದು ಹೇಗೆ ಮತ್ತು ಫ್ರಂಟ್‌ಎಂಡ್ vs ಬ್ಯಾಕೆಂಡ್ ನೋಡಿ.

CORS ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

ಪೂರ್ಣ ಕನ್ಸೋಲ್ ದೋಷ ಮತ್ತು ವಿಫಲ ವಿನಂತಿಯ ಸ್ಥಿತಿ ಕೋಡ್ ಓದಿದೆ
ಗುಪ್ತ 404 ಅಥವಾ 500 ಇಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಂಡೆ
ರಹಸ್ಯ ಕೀ ಇರುವ APIಗಳನ್ನು ಬ್ರೌಸರ್‌ನಿಂದ ಅಲ್ಲ, ಬ್ಯಾಕೆಂಡ್‌ನಿಂದ ಕರೆಯಲಾಗುತ್ತದೆ
ಸರ್ವರ್ ನಿಖರ ಅನುಮತಿ ಪಟ್ಟಿಯೊಂದಿಗೆ Access-Control-Allow-Origin ಕಳುಹಿಸುತ್ತದೆ
OPTIONS ಪ್ರಿಫ್ಲೈಟ್ ಅನುಮತಿಸಿದ ವಿಧಾನಗಳು ಮತ್ತು ಹೆಡರ್‌ಗಳೊಂದಿಗೆ, ದೃಢೀಕರಣಕ್ಕಿಂತ ಮುಂಚೆ ಉತ್ತರಿಸಲ್ಪಡುತ್ತದೆ
ದೋಷ ಪ್ರತಿಕ್ರಿಯೆಗಳಲ್ಲಿಯೂ CORS ಹೆಡರ್‌ಗಳಿವೆ
ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳು: ನಿಖರ ಆರಿಜಿನ್, Allow-Credentials: true, ಸರಿಯಾದ ಕುಕೀ ಸೆಟ್ಟಿಂಗ್‌ಗಳು
ಪ್ರಿವ್ಯೂ, ಪ್ರಕಟಿತ ಮತ್ತು ಕಸ್ಟಮ್-ಡೊಮೇನ್ ಆರಿಜಿನ್‌ಗಳೆಲ್ಲ ಒಳಗೊಂಡಿವೆ, ಅಥವಾ ಸಾಪೇಕ್ಷ /api ಮಾರ್ಗಗಳನ್ನು ಬಳಸಲಾಗಿದೆ
no-cors, ಸಾರ್ವಜನಿಕ ಪ್ರಾಕ್ಸಿಗಳು, ಅಥವಾ ಯಾವುದೇ-ಆರಿಜಿನ್ ಪ್ರತಿಫಲನ ಶಾರ್ಟ್‌ಕಟ್‌ಗಳಿಲ್ಲ

ಪ್ರಶ್ನೆಗಳು

CORS error ಎಂದರೆ ಏನು?

ನಿಮ್ಮ ಪುಟವು ಒಂದು ಆರಿಜಿನ್‌ನಿಂದ ಲೋಡ್ ಆಗಿ, ಬೇರೆ ಆರಿಜಿನ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆ ಓದಲು ಪ್ರಯತ್ನಿಸಿತು, ಮತ್ತು ಆ ಸರ್ವರ್‌ನ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಅದನ್ನು ಅನುಮತಿಸುವ ಹೆಡರ್‌ಗಳಿಲ್ಲ. ಬ್ರೌಸರ್ ನಿಮ್ಮ ಕೋಡ್ ಆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಓದುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಪರಿಹಾರ ಸರ್ವರ್‌ನಲ್ಲಿ ಅಥವಾ ವಿನಂತಿ ರೂಟ್ ಆಗುವ ರೀತಿಯಲ್ಲಿ ಇರುತ್ತದೆ, ಫ್ರಂಟ್‌ಎಂಡ್ ಕೋಡ್‌ನಲ್ಲಿ ಅಲ್ಲ.

ಫ್ರಂಟ್‌ಎಂಡ್‌ನಿಂದ CORS error ಸರಿಪಡಿಸಬಹುದೇ?

ಸರಿಯಾಗಿ ಇಲ್ಲ. mode: 'no-cors' ನಂತಹ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿಮ್ಮ ಕೋಡ್‌ನಿಂದ ಮರೆಮಾಡುತ್ತವೆ ಅಷ್ಟೇ. ಸರ್ವರ್ ಸರಿಯಾದ Access-Control-Allow-Origin ಹೆಡರ್ ಕಳುಹಿಸುವಂತೆ ಮಾಡಿ, ಅಥವಾ API ಅನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಬ್ಯಾಕೆಂಡ್ ಅಥವಾ ಒಂದೇ ಆರಿಜಿನ್‌ನ ಪ್ರಾಕ್ಸಿಯ ಮೂಲಕ ಕರೆಯಿರಿ.

Access-Control-Allow-Origin: * ಸುರಕ್ಷಿತವೇ?

ಯಾರಾದರೂ ಓದಬಹುದಾದ ಸಾರ್ವಜನಿಕ ಡೇಟಾಕ್ಕೆ, ಉದಾಹರಣೆಗೆ ಲಾಗಿನ್ ಇಲ್ಲದ ಸಾರ್ವಜನಿಕ API ಗೆ ಇದು ಸರಿ. ಇದನ್ನು ಕುಕೀಗಳು ಅಥವಾ ಇತರ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳೊಂದಿಗೆ ಬಳಸಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಖಾಸಗಿ API ಗಳಿಗೆ ಅನುಮತಿಸಲಾದ ನಿಖರ ಆರಿಜಿನ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಬೇಕು.

ನನ್ನ ವಿನಂತಿ Postman ಅಥವಾ curl ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಏಕೆ ಆಗುವುದಿಲ್ಲ?

CORS ಅನ್ನು ಜಾರಿಗೊಳಿಸುವುದು ಬ್ರೌಸರ್‌ಗಳು ಮಾತ್ರ. Postman ಮತ್ತು curl ನಂತಹ ಉಪಕರಣಗಳು ಅದನ್ನು ಅನ್ವಯಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ವಿನಂತಿ ಅಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಬಹುದು, ಆದರೆ ಪುಟದ JavaScript ಅದನ್ನು ಮಾಡಿದಾಗ ಬ್ಲಾಕ್ ಆಗಬಹುದು.

ಪ್ರಿಫ್ಲೈಟ್ ವಿನಂತಿ ಎಂದರೆ ಏನು?

ಸರಳವಲ್ಲದ ವಿನಂತಿಗಳಿಗೆ, ಉದಾಹರಣೆಗೆ JSON POST ಅಥವಾ Authorization ಹೆಡರ್ ಇರುವ ವಿನಂತಿಗೆ, ಬ್ರೌಸರ್ ಮೊದಲು OPTIONS ವಿನಂತಿ ಕಳುಹಿಸುತ್ತದೆ, ಯಾವ ವಿಧಾನಗಳು ಮತ್ತು ಹೆಡರ್‌ಗಳು ಅನುಮತಿಸಲ್ಪಟ್ಟಿವೆ ಎಂದು ಸರ್ವರ್‌ನನ್ನು ಕೇಳಲು. ಆ OPTIONS ವಿನಂತಿ ವಿಫಲವಾದರೆ ಅಥವಾ ಸರಿಯಾದ ಹೆಡರ್‌ಗಳಿಲ್ಲದಿದ್ದರೆ, ನಿಜವಾದ ವಿನಂತಿ ಎಂದಿಗೂ ಕಳುಹಿಸಲ್ಪಡುವುದಿಲ್ಲ.