streamalism.org

1. Bemutatkozás

Ebben a cikkben azt vizsgáljuk, hogy miként vezérelhetjük a HTTP gyorsítótárat a Spring Security segítségével.

Bemutatjuk az alapértelmezett viselkedését, és elmagyarázzuk a mögöttes érvelést. Ezután megvizsgáljuk a viselkedés részleges vagy teljes megváltoztatásának módjait.

2. Gyorsítótár alapértelmezett viselkedése

A gyorsítótár-vezérlő fejlécek hatékony használatával utasíthatjuk böngészőnket az erőforrások gyorsítótárba helyezésére és a hálózati ugrások elkerülésére. Ez csökkenti a várakozási időt és a szerverünk terhelését.

Alapértelmezés szerint a Spring Security meghatározott gyorsítótár-vezérlő fejléc értékeket állít be számunkra, anélkül, hogy bármit konfigurálnunk kellene.

Először állítsuk be a Spring Security alkalmazást:

@Configuration @EnableWebSecurity @EnableGlobalMethodSecurity nyilvános osztály A SpringSecurityConfig kiterjeszti a WebSecurityConfigurerAdapter {@Override protected void configure (HttpSecurity http) dobja a kivételeket {}}

Felülírjuk Beállítás() ha semmit sem teszünk, ez azt jelenti, hogy nem kell hitelesítenünk a végpont eléréséhez, ami lehetővé teszi számunkra, hogy pusztán a gyorsítótár tesztelésére összpontosítsunk.

Ezután valósítsunk meg egy egyszerű REST végpontot:

@GetMapping ("/ default / users / {name}") public ResponseEntity getUserWithDefaultCaching (@PathVariable String name) {return ResponseEntity.ok (new UserDto (név)); }

A kapott gyorsítótár-vezérlés fejléc így fog kinézni:

[cache-control: no-cache, no-store, max-age = 0, must-revalidate]

Végül hajtsunk végre egy tesztet, amely eléri a végpontot, és állítsuk be, hogy milyen fejléceket küldünk a válaszban:

adott () .when () .get (getBaseUrl () + "/ default / users / Michael") .then () .header ("Cache-Control", "no-cache, no-store, max-age = 0 , must-revalidate ") .header (" Pragma "," no-cache ");

Lényegében ez azt jelenti, hogy a böngésző soha nem tárolja gyorsítótárba ezt a választ.

Bár ez hatástalannak tűnhet, valójában jó oka van ennek az alapértelmezett viselkedésnek - Ha egy felhasználó kijelentkezik, egy másik pedig bejelentkezik, akkor nem akarjuk, hogy láthassák a korábbi felhasználói erőforrásokat. Sokkal biztonságosabb, ha alapértelmezés szerint nem tárolunk semmit gyorsítótárba, és ránk hagyhatunk felelősséget a gyorsítótárazás kifejezett engedélyezéséért.

3. Az alapértelmezett gyorsítótár-viselkedés felülbírálása

Néha előfordulhat, hogy olyan erőforrásokkal foglalkozunk, amelyeket tárolni szeretnénk. Ha engedélyezni fogjuk, akkor a legbiztonságosabb erőforrásonként megtenni. Ez azt jelenti, hogy más erőforrások továbbra sem kerülnek gyorsítótárba alapértelmezés szerint.

Ehhez próbáljuk meg felülbírálni a gyorsítótár-vezérlő fejléceket egyetlen kezelő módszerrel, a CacheControl gyorsítótár. A CacheControl class folyékony készítő, amely megkönnyíti számunkra a különböző típusú gyorsítótárak létrehozását:

@GetMapping ("/ users / {name}") public ResponseEntity getUser (@PathVariable String name) {return ResponseEntity.ok () .cacheControl (CacheControl.maxAge (60, TimeUnit.SECONDS)) .body (new UserDto (név) ); }

Tesztünk során érjük el ezt a végpontot, és állítsuk be, hogy megváltoztattuk a fejléceket:

adott () .when () .get (getBaseUrl () + "/ users / Michael") .then () .header ("Cache-Control", "max-age = 60");

Mint láthatjuk, felülbíráltuk az alapértelmezéseket, és most egy böngésző 60 másodpercig tárolja a válaszunkat.

4. Az alapértelmezett gyorsítótár-viselkedés kikapcsolása

A Spring Security alapértelmezett gyorsítótár-vezérlő fejléceit is teljesen kikapcsolhatjuk. Ez meglehetősen kockázatos dolog, és nem igazán ajánlott. De, ha nagyon akarjuk, akkor kipróbálhatjuk a Beállítás módszere WebSecurityConfigurerAdapter:

A @Orride protected void configure (HttpSecurity http) a Kivételt dobja {http.headers (). Disable (); }

Most kérjünk újra a végpontunkhoz, és nézzük meg, milyen választ kapunk:

adott () .when () .get (getBaseUrl () + "/ default / users / Michael") .then () .headers (új HashMap ());

Mint láthatjuk, egyáltalán nem állítottak be gyorsítótár fejléceket. Újra, ez nem biztonságos, de azt bizonyítja, hogyan kapcsolhatjuk ki az alapértelmezett fejléceket, ha akarjuk.

5. Következtetés

Ez a cikk bemutatja, hogy a Spring Security hogyan tiltja alapértelmezés szerint a HTTP gyorsítótárat, és elmagyarázza, hogy ez azért van, mert nem akarjuk a gyorsítótárat gyorsítótárba helyezni. Láttuk azt is, hogyan tilthatjuk le vagy módosíthatjuk ezt a viselkedést, ahogyan azt jónak látjuk.

Ezeknek a példáknak és kódrészleteknek a megvalósítása megtalálható a GitHub projektben - ez egy Maven projekt, ezért könnyen importálhatónak és futtathatónak kell lennie.