Spring Security - Cache Control Headers

1. Introduksjon

I denne artikkelen vil vi undersøke hvordan vi kan kontrollere HTTP-caching med Spring Security.

Vi vil demonstrere standardoppførselen, og forklare begrunnelsen bak den. Vi vil deretter se på måter å endre denne oppførselen, helt eller delvis.

2. Standard caching-atferd

Ved å bruke cache-kontrolloverskrifter effektivt, kan vi instruere nettleseren vår om å cache ressurser og unngå nettverkshopp. Dette reduserer ventetiden, og også belastningen på serveren vår.

Som standard setter Spring Security spesifikke topptekstverdier for cache for oss, uten at vi trenger å konfigurere noe.

La oss først sette opp vårsikkerhet for applikasjonen vår:

@Configuration @EnableWebSecurity @EnableGlobalMethodSecurity offentlig klasse SpringSecurityConfig utvider WebSecurityConfigurerAdapter {@Override-beskyttet tomkonfigurasjon (HttpSecurity http) kaster unntak {}}

Vi overstyrer konfigurer () for å gjøre ingenting, betyr dette at vi ikke trenger å bli autentisert for å treffe et endepunkt, slik at vi kan fokusere på rent testing av caching.

Deretter la oss implementere et enkelt REST-sluttpunkt:

@GetMapping ("/ standard / brukere / {navn}") offentlig ResponseEntity getUserWithDefaultCaching (@PathVariable strengnavn) {return ResponseEntity.ok (ny UserDto (navn)); }

Resultatet cache-kontroll header vil se slik ut:

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

Til slutt, la oss implementere en test som treffer endepunktet, og hevde hvilke overskrifter som sendes i svaret:

gitt () .when () .get (getBaseUrl () + "/ default / brukere / Michael") .then () .header ("Cache-Control", "no-cache, no-store, max-age = 0 , må-validere "). header (" Pragma "," no-cache ");

I hovedsak betyr dette at en nettleser aldri vil cache dette svaret.

Selv om dette kan virke ineffektivt, er det faktisk en god grunn til denne standardoppførselen - Hvis en bruker logger ut og en annen logger inn, vil vi ikke at de skal kunne se de tidligere brukerressursene. Det er mye tryggere å ikke cache noe som standard, og la oss være ansvarlige for å aktivere caching eksplisitt.

3. Overstyring av standard caching-atferd

Noen ganger har vi kanskje å gjøre med ressurser som vi ønsker å bli bufret. Hvis vi skal aktivere det, ville det være tryggest å gjøre det per ressursbasis. Dette betyr at andre ressurser fortsatt ikke blir hurtigbufret som standard.

For å gjøre dette, la oss prøve å overstyre cache-kontrolloverskriftene i en enkelt behandlingsmetode ved hjelp av CacheControl cache. De CacheControl class er en flytende byggherre, noe som gjør det enkelt for oss å lage forskjellige typer hurtigbufring:

@GetMapping ("/ brukere / {navn}") offentlig ResponseEntity getUser (@PathVariable String name) {return ResponseEntity.ok () .cacheControl (CacheControl.maxAge (60, TimeUnit.SECONDS)) .body (ny UserDto (navn) ); }

La oss treffe dette endepunktet i testen, og hevde at vi har endret overskrifter:

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

Som vi kan se, har vi overstyrt standardinnstillingene, og nå vil svaret vårt bli bufret av en nettleser i 60 sekunder.

4. Slå av standard caching-atferd

Vi kan også slå av standard cache-kontrolloverskrifter for Spring Security helt. Dette er ganske risikabelt å gjøre, og egentlig ikke anbefalt. Men hvis vi virkelig vil, kan vi prøve det ved å overstyre konfigurere metoden for WebSecurityConfigurerAdapter:

@ Override beskyttet ugyldig konfigurasjon (HttpSecurity http) kaster unntak {http.headers (). Deaktiver (); }

La oss nå be om endepunktet igjen og se hvilket svar vi får:

gitt () .when () .get (getBaseUrl () + "/ default / users / Michael") .then () .headers (new HashMap ());

Som vi kan se, er det ikke satt noen cacheoverskrifter i det hele tatt. En gang til, dette er ikke sikkert, men viser hvordan vi kan slå av standardhodene hvis vi vil.

5. Konklusjon

Denne artikkelen demonstrerer hvordan Spring Security deaktiverer HTTP-caching som standard og forklarer at dette er fordi vi ikke vil cache sikre ressurser. Vi har også sett hvordan vi kan deaktivere eller endre denne oppførselen etter eget ønske.

Implementeringen av alle disse eksemplene og kodebitene finnes i GitHub-prosjektet - dette er et Maven-prosjekt, så det skal være enkelt å importere og kjøre som det er.


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