Megértése pók, tavasszal oroszul!
Az egyszerű CORS lekérdezések feldolgozása
A legegyszerűbb esetben az interdomain interakciók GET, POST vagy HEAD kéréssel kezdődnek egy erőforráshoz a kiszolgálón. Ebben az esetben a POST kérés tartalmi típusa az alkalmazás / x-www-form-urlen kódolásra korlátozódik. multipart / form-data vagy text / plain. A kérelem tartalmazza az Origin fejlécet. amely az ügyfélkód eredetét jelzi.
A szerver figyelembe veszi a kérelem eredetét, és elfogadja vagy elutasítja a kérelem feldolgozását. Ha a szerver elfogadja a kérést, akkor a hozzáférési vezérlővel engedélyezett erőforrással válaszol az Access-Control-Allow-Origin fejlécben. Ez a fejléc jelzi az ügyfél számára, hogy honnan származik az ügyfél az erőforráshoz való hozzáféréshez. Figyelembe véve, hogy az Access-Control-Allow-Origin megfelel a kérés eredetének, a böngésző feloldja a kérelmet.
Másrészről, ha az Access-Control-Allow-Origin nem jelenik meg a válaszban, vagy ha nem a kérés eredete, a böngésző nem engedélyezi a kérelmet.
Tegyük fel például, hogy az ügyfélkód a foo.client.com webhelyen található, és kérést küld a bar.server.com címre:
Emellett az Access-Control-Allow-Origin beállítása "*" -ra állítható, jelezve a rendelkezésre állást mindenkinek. Ez nem biztonságos gyakorlatnak számít, kivéve azokat a különleges eseteket, amelyekben az API teljesen nyilvános és bármely ügyfél számára szánták.
Preflight vizsgálatok
Ha a lekérdezés befolyásolhatja a felhasználói adatokat, akkor egy egyszerű lekérdezés nem elegendő. Ehelyett a CORS-prefixált kérelmet elküldik a kérelem elküldése előtt, hogy biztosítsák a kérés biztonságát. Előzetes ellenőrzési lekérdezésekre van szükség, ha a GET, a POST, a HEAD vagy a POST kérés tartalomtípusától eltérő HTTP-módszer eltér az alkalmazás / x-www-form-urlencodedtől. multipart / form-data vagy text / plain. Továbbá, ha a kérelem tartalmazza a saját fejléceit, akkor elővilágítási kérelemre van szükség.
Tegyük fel például, hogy egy ügyfél, amely az foo.client.com webhelyen található, DELETE kérést küld a nem a bar.server.com forráshoz. Az elővigyázatos lekérdezés az OPTIONS kérelem formanyomtatványt használja az alábbi fejlécekkel:
Az előzetes lekérdezés ténylegesen megkérdezi a kiszolgálót a DELETE kérelem elérhetőségéről anélkül, hogy maga a DELETE kérést elküldte volna. Ha a szerver ilyen kérést rendez, az elővigyázatossági kérelemre válaszol:
Az elővilágítási kérelemre adott válasz (az Access-Control-Allow-Methods fejlécében) azt jelzi, hogy az ügyfél a DELETE kérés számára elérhető az átadandó erőforráshoz. Az Access-Control-Max-Age fejléc azt jelzi, hogy ez az elővilágítási válasz 84600 másodperc vagy egy nap, amely után új elővilágítási kérelmet kell végrehajtani.
Ugyanakkor az ügyfél képes lesz az aktuális DELETE kérelmet elküldeni az erőforrásnak.
A lecke eredeti szövegét a spring.io-ra olvashatja.