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.


$config[zx-auto] not found$config[zx-overlay] not found