401-esek javítása CORS előrepülésekkel és rugóbiztonsággal
1. Áttekintés
Ebben a rövid oktatóanyagban megtanuljuk, hogyan lehet megoldani a hibát: „Az elővilágításra adott válasz érvénytelen 401 HTTP-állapotkóddal rendelkezik” hibaüzenet, amely előfordulhat olyan alkalmazásokban, amelyek támogatják a keresztirányú kommunikációt és a Spring Security szolgáltatást használják.
Először meglátjuk, hogy mi a kereszt-származási kérelem, majd kijavítunk egy problémás példát.
2. Kereszt származási kérelmek
A kereszt-eredetű kérelmek röviden olyan HTTP-kérelmek, amelyekben a kérés eredete és célja eltér. Ez a helyzet például akkor, amikor egy webalkalmazást egy tartományból szolgáltatnak, és a böngésző AJAX-kérést küld egy másik tartományban lévő kiszolgálónak.
Az eredetközi kérelmek kezeléséhez a kiszolgálónak engedélyeznie kell egy bizonyos mechanizmust, amelyet CORS-nak vagy kereszt-eredetű erőforrás-megosztásnak neveznek.
A CORS első lépése egy OPCIÓK kérést annak megállapításához, hogy a kérelem célpontja támogatja-e. Ezt repülés előtti kérésnek nevezzük.
A szerver ezután a repülés előtti kérésre fejlécek gyűjteményével válaszolhat:
- Access-Control-Allow-Origin: Meghatározza, hogy mely eredetek férhetnek hozzá az erőforráshoz. A „*” bármilyen eredetet jelent
- Hozzáférés-vezérlés-Engedélyezés-módszerek: Jelzi a megengedett HTTP-módszereket a kereszt-származási kérelmekhez
- Belépés-vezérlés-Fejlécek engedélyezése: Jelzi a kereszt-származási kérelmek engedélyezett kérésfejlécét
- Access-Control-Max-Age: Meghatározza a gyorsítótárazott előrepülési kérelem eredményének lejárati idejét
Tehát, ha a repülés előtti kérelem nem felel meg az e válaszfejlécekben meghatározott feltételeknek, a tényleges nyomonkövetési kérelem hibákat vet fel a kereszt-származási kéréssel kapcsolatban.
Könnyű hozzáadni a CORS-támogatást a Spring-powered szolgáltatásunkhoz, de ha helytelenül konfiguráljuk, akkor ez a repülés előtti kérés mindig kudarcot vall egy 401-esnél.
3. CORS-kompatibilis REST API létrehozása
A probléma szimulálásához először hozzunk létre egy egyszerű REST API-t, amely támogatja a kereszt-eredetű kéréseket:
@RestController @CrossOrigin ("// localhost: 4200") public class ResourceController {@GetMapping ("/ user") public String user (Principal megbízó) {return princip.getName (); }}
A @CrossOrigin az annotáció biztosítja, hogy az API -ink csak az érvelésében említett eredetről érhetők el.
4. A REST API biztosítása
Biztosítsuk most a REST API-t a Spring Security segítségével:
@EnableWebSecurity nyilvános osztály A WebSecurityConfig kiterjeszti a WebSecurityConfigurerAdapter {@Override protected void configure (HttpSecurity http) dobja a {http .authorizeRequests () .anyRequest (). Hitelesített () .and () .httpBasic (); }}
Ebben a konfigurációs osztályban kikényszerítettük az engedélyt az összes beérkező kérelemre. Ennek eredményeként minden kérést érvényes engedélyezési token nélkül elutasít.
5. Repülés előtti kérelem benyújtása
Most, hogy létrehoztuk a REST API-t, próbálkozzunk egy repülés előtti kéréssel becsavar:
curl -v -H "Access-Control-Request-Method: GET" -H "Origin: // localhost: 4200" -X OPTIONS // localhost: 8080 / user ... <HTTP / 1.1 401 ... <WWW -Authenticate: Basic realm = "Realm" ... <Vary: Origin <Vary: Access-Control-Request-Method <Vary: Access-Control-Request-Headers <Access-Control-Request-Headers <Access-Control-Allow-Origin: // localhost: 4200 <Hozzáférés-vezérlés-Engedélyezési módszerek: POST <Hozzáférés-vezérlés-Engedélyezés-hitelesítő adatok: igaz <Engedélyezés: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH ...
A parancs kimenetéből ezt láthatjuk a kérelmet egy 401-es elutasították.
Mivel ez a becsavar parancsot, nem látjuk a kimenetben „Az előzetes ellenőrzésre érvénytelen 401 HTTP-állapotkódot” hibát.
De ezt a pontos hibát megismételhetjük egy olyan kezelőfelület-alkalmazás létrehozásával, amely a REST API-t egy másik tartományból emészti fel, és egy böngészőben futtatja azt.
6. A megoldás
A tavaszi biztonsági konfigurációban nem zártuk ki egyértelműen az előzetes kérelmeket az engedélyezésből. Ne feledje, hogy a Spring Security biztosítja minden végpontok alapértelmezés szerint.
Ennek eredményeként API-junk az OPTIONS kérésben is engedélyezési tokent vár.
A Spring dobozon kívüli megoldást kínál az OPTIONS kérések kizárására az engedélyellenőrzésekből:
@EnableWebSecurity nyilvános osztály A WebSecurityConfig kiterjeszti a WebSecurityConfigurerAdapter {@Orride protected void configure (HttpSecurity http) dobja a Kivételt {// ... http.cors (); }}
A cors () metódus hozzáadja a Spring által biztosított CorsFilter az alkalmazáskörnyezetbe, amely viszont megkerüli az OPTIONS kérések engedélyezési ellenőrzését.
Most újra tesztelhetjük az alkalmazásunkat, és láthatjuk, hogy működik.
7. Következtetés
Ebben a rövid cikkben megtanultuk, hogyan lehet kijavítani az „Az előzetes ellenőrzésre adott válasz érvénytelen 401 HTTP-állapotkódot” hibát, amely a Spring Security és a cross-origin kérésekhez kapcsolódik.
Ne feledje, hogy a példa szerint az ügyfélnek és az API-nak különböző tartományokon vagy portokon kell futnia a probléma újbóli létrehozásához. Például leképezhetjük az alapértelmezett hosztnevet az ügyfélre, a gép IP-címét pedig a REST API-ra, amikor egy helyi gépen fut.
Mint mindig, az oktatóanyagban bemutatott példa megtalálható a Githubon.