CORS ਗਲਤੀਆਂ ਕਿਵੇਂ ਠੀਕ ਕਰੀਏ (ਅਤੇ ਇਹ ਕਿਉਂ ਆਉਂਦੀਆਂ ਹਨ)
CORS ਗਲਤੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡੇ ਵੈੱਬ ਪੰਨੇ ਨੇ ਕਿਸੇ ਹੋਰ ਮੂਲ (ਹੋਰ ਡੋਮੇਨ, ਪੋਰਟ ਜਾਂ ਪ੍ਰੋਟੋਕੌਲ) ਤੋਂ ਜਵਾਬ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਅਤੇ ਉਸ ਸਰਵਰ ਨੇ ਇਹ ਦੱਸਣ ਵਾਲੇ ਹੈਡਰ ਨਹੀਂ ਭੇਜੇ ਕਿ ਇਹ ਮਨਜ਼ੂਰ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਰੱਖਿਆ ਲਈ ਜਵਾਬ ਰੋਕ ਦਿੰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਸਰਵਰ ਉੱਤੇ ਠੀਕ ਕਰਦੇ ਹੋ, ਆਪਣੀ ਸਾਈਟ ਦੇ ਮੂਲ ਲਈ 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 (ਵੱਖਰਾ ਪੋਰਟ, ਇਸ ਲਈ ਵੱਖਰਾ ਮੂਲ) |
ਬ੍ਰਾਊਜ਼ਰ ਸਮਾਨ-ਮੂਲ ਨੀਤੀ ਮੰਨਦੇ ਹਨ: ਪੰਨੇ ਦਾ 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 ਜਾਂ 404 ਠੀਕ ਕਰੋ, ਅਤੇ 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.comAccess-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETEAccess-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ਅਤੇ ਪ੍ਰੀਵਿਊ ਮੂਲ ਮਨਜ਼ੂਰ ਹੋਣ, 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 ਤੋਂ ਬਚੋ
ਅਕਸਰ ਸਭ ਤੋਂ ਸਾਫ਼ ਹੱਲ ਹੈ ਕਿ ਕੋਈ ਕਰਾਸ-ਮੂਲ ਬੇਨਤੀ ਹੀ ਨਾ ਕਰੋ। 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: true ਚਾਹੀਦਾ ਹੈ |
| "CORS ਗਲਤੀ" ਪਰ Network ਟੈਬ ਵਿੱਚ 500 | ਪਹਿਲਾਂ ਸਰਵਰ ਦੀ ਗਲਤੀ ਠੀਕ ਕਰੋ |
API URL localhost ਵਿੱਚ ਹਾਰਡ-ਕੋਡ | ਰਿਸ਼ਤੇਦਾਰ ਪਾਥ ਜਾਂ ਹਰ ਵਾਤਾਵਰਣ ਲਈ ਸੈਟਿੰਗ ਵਰਤੋ |
Mythex ਵਿੱਚ CORS
ਜਦੋਂ ਕਿਸੇ Mythex ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵੈੱਬਸਾਈਟ ਅਤੇ API ਸਰਵਰ ਦੋਵੇਂ ਹੋਣ, ਤਾਂ ਦੋਵੇਂ ਇੱਕੋ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸੇਵਾਵਾਂ ਵਜੋਂ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਪ੍ਰੀਵਿਊ ਵਿੱਚ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਬਦਲ ਸਕਦੇ ਹੋ। ਏਜੰਟ ਨੂੰ ਕਹਿਣਾ ਕਿ ਫਰੰਟ ਐਂਡ ਬੈਕਐਂਡ ਨੂੰ ਰਿਸ਼ਤੇਦਾਰ /api ਪਾਥ ਰਾਹੀਂ ਬੁਲਾਵੇ, ਵਿਕਾਸ ਵਿੱਚ ਪ੍ਰੌਕਸੀ ਕੀਤਾ ਹੋਇਆ, ਜ਼ਿਆਦਾਤਰ CORS ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਕਰਾਸ-ਮੂਲ ਕਾਲਾਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਤਾਂ ਏਜੰਟ ਨੂੰ ਕੰਸੋਲ ਦੀ ਹੂ-ਬ-ਹੂ ਗਲਤੀ ਅਤੇ ਸ਼ਾਮਲ ਮੂਲ ਦਿਓ। ਨਤੀਜਾ ਪ੍ਰਕਾਸ਼ਿਤ ਐਪ ਉੱਤੇ ਵੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਉਸਦਾ ਪਤਾ ਪ੍ਰੀਵਿਊ ਤੋਂ ਵੱਖਰਾ ਹੈ। ਡੌਕਸ ਵਿੱਚ Multi-service apps ਅਤੇ API backends ਵੇਖੋ, ਅਤੇ ਸਾਡੀਆਂ ਗਾਈਡਾਂ AI ਨਾਲ ਬਣੀ ਐਪ ਵਿੱਚ ਗਲਤੀਆਂ ਲੱਭਣ ਅਤੇ ਫਰੰਟਐਂਡ ਬਨਾਮ ਬੈਕਐਂਡ ਵੇਖੋ।
CORS ਚੈੱਕਲਿਸਟ
- ਪੂਰੀ ਕੰਸੋਲ ਗਲਤੀ ਅਤੇ ਫੇਲ੍ਹ ਹੋਈ ਬੇਨਤੀ ਦਾ ਸਟੇਟਸ ਕੋਡ ਪੜ੍ਹਿਆ
- ਲੁਕੀ ਹੋਈ 404 ਜਾਂ 500 ਨੂੰ ਰੱਦ ਕੀਤਾ
- ਗੁਪਤ ਕੀ ਵਾਲੀਆਂ API ਬੈਕਐਂਡ ਤੋਂ ਬੁਲਾਈਆਂ, ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਨਹੀਂ
- ਸਰਵਰ
Access-Control-Allow-Originਹੂ-ਬ-ਹੂ ਮਨਜ਼ੂਰ ਮੂਲਾਂ ਨਾਲ ਭੇਜਦਾ ਹੈ -
OPTIONSਪ੍ਰੀਫਲਾਈਟ ਮਨਜ਼ੂਰ ਮੈਥਡ ਅਤੇ ਹੈਡਰਾਂ ਨਾਲ ਜਵਾਬ ਦਿੱਤਾ, ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਪਹਿਲਾਂ - ਗਲਤੀ ਜਵਾਬਾਂ ਉੱਤੇ ਵੀ CORS ਹੈਡਰ ਮੌਜੂਦ
- ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ: ਹੂ-ਬ-ਹੂ ਮੂਲ,
Allow-Credentials: true, ਸਹੀ ਕੂਕੀ ਸੈਟਿੰਗਾਂ - ਪ੍ਰੀਵਿਊ, ਪ੍ਰਕਾਸ਼ਿਤ ਅਤੇ ਕਸਟਮ-ਡੋਮੇਨ ਮੂਲ ਸਭ ਕਵਰ, ਜਾਂ ਰਿਸ਼ਤੇਦਾਰ
/apiਪਾਥ ਵਰਤੇ -
no-cors, ਜਨਤਕ ਪ੍ਰੌਕਸੀਆਂ, ਜਾਂ ਕੋਈ ਵੀ ਮੂਲ ਵਾਪਸ ਭੇਜਣ ਵਾਲੇ ਸ਼ਾਰਟਕੱਟ ਨਹੀਂ
ਸਵਾਲ
CORS ਗਲਤੀ ਦਾ ਕੀ ਮਤਲਬ ਹੈ?
ਤੁਹਾਡੇ ਪੰਨੇ ਨੇ, ਜੋ ਇੱਕ ਮੂਲ ਤੋਂ ਲੋਡ ਹੋਇਆ, ਕਿਸੇ ਹੋਰ ਮੂਲ ਤੋਂ ਜਵਾਬ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ, ਅਤੇ ਉਸ ਸਰਵਰ ਦੇ ਜਵਾਬ ਵਿੱਚ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲੇ ਹੈਡਰ ਨਹੀਂ ਸਨ। ਬ੍ਰਾਊਜ਼ਰ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਜਵਾਬ ਪੜ੍ਹਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਹੱਲ ਸਰਵਰ ਜਾਂ ਬੇਨਤੀ ਦੇ ਰੂਟਿੰਗ ਵਿੱਚ ਹੈ, ਫਰੰਟ ਐਂਡ ਕੋਡ ਵਿੱਚ ਨਹੀਂ।
ਕੀ ਮੈਂ ਫਰੰਟ ਐਂਡ ਤੋਂ CORS ਗਲਤੀ ਠੀਕ ਕਰ ਸਕਦਾ ਹਾਂ?
ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ। 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 ਬੇਨਤੀ ਫੇਲ੍ਹ ਹੋਵੇ ਜਾਂ ਸਹੀ ਹੈਡਰ ਨਾ ਹੋਣ, ਤਾਂ ਅਸਲ ਬੇਨਤੀ ਭੇਜੀ ਹੀ ਨਹੀਂ ਜਾਂਦੀ।