streamalism.org

1. Introduktion

I denne artikel undersøger vi, hvordan vi kan styre HTTP-caching med Spring Security.

Vi demonstrerer dens standardadfærd og forklarer også ræsonnementet bag det. Vi vil derefter se på måder at ændre denne adfærd på, helt eller delvist.

2. Standard cachingadfærd

Ved at bruge cache-kontroloverskrifter effektivt kan vi instruere vores browser om at cache ressourcer og undgå netværkshops. Dette mindsker latenstiden og også belastningen på vores server.

Som standard indstiller Spring Security specifikke cache-kontrol-headerværdier for os uden at vi behøver at konfigurere noget.

Lad os først konfigurere Spring Security til vores applikation:

@Configuration @EnableWebSecurity @EnableGlobalMethodSecurity offentlig klasse SpringSecurityConfig udvider WebSecurityConfigurerAdapter {@ Override-beskyttet ugyldig konfiguration (HttpSecurity http) kaster undtagelse {}}

Vi overstyrer konfigurer () for ikke at gøre noget betyder det, at vi ikke behøver at blive godkendt for at nå et slutpunkt, så vi kan fokusere på rent test af caching.

Lad os derefter implementere et simpelt REST-slutpunkt:

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

Den resulterende cache-kontrol header vil se sådan ud:

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

Endelig lad os implementere en test, der rammer slutpunktet, og hævde, hvilke overskrifter der sendes i svaret:

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

I det væsentlige betyder det, at en browser aldrig cache dette svar.

Selvom dette kan virke ineffektivt, er der faktisk en god grund til denne standardadfærd - Hvis en bruger logger ud og en anden logger ind, ønsker vi ikke, at de skal kunne se de tidligere brugerressourcer. Det er meget sikrere at ikke cache noget som standard og lade os være ansvarlige for at aktivere caching eksplicit.

3. Tilsidesættelse af standardcachingadfærd

Nogle gange har vi måske at gøre med ressourcer, som vi ønsker at blive cache. Hvis vi vil aktivere det, ville det være sikreste at gøre det pr. Ressource. Dette betyder, at andre ressourcer stadig ikke caches som standard.

For at gøre dette, lad os prøve at tilsidesætte cache-kontroloverskrifterne i en enkelt behandlingsmetode ved hjælp af CacheControl cache. Det CacheControl class er en flydende bygherre, hvilket gør det let for os at oprette forskellige typer caching:

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

Lad os ramme dette slutpunkt i vores test og hævde, at vi har ændret overskrifter:

givet () .when () .get (getBaseUrl () + "/ brugere / Michael"). derefter () .header ("Cache-Control", "max-age = 60");

Som vi kan se, har vi tilsidesat standardindstillingerne, og nu caches vores svar af en browser i 60 sekunder.

4. Deaktivering af standardcachingadfærd

Vi kan også slukke for standardcache-overskrifterne for Spring Security helt. Dette er en ganske risikabel ting at gøre, og det anbefales ikke rigtig. Men hvis vi virkelig vil, så kan vi prøve det ved at tilsidesætte konfigurere metode til WebSecurityConfigurerAdapter:

@ Override beskyttet ugyldig konfiguration (HttpSecurity http) kaster undtagelse {http.headers (). Deaktiver (); }

Lad os nu gøre en anmodning til vores slutpunkt igen og se, hvilket svar vi får:

givet () .when () .get (getBaseUrl () + "/ standard / brugere / Michael"). derefter () .headers (ny HashMap ());

Som vi kan se, er der slet ikke angivet nogen cacheoverskrifter. Igen, dette er ikke sikkert, men beviser, hvordan vi kan slå standardoverskrifterne fra, hvis vi ønsker det.

5. Konklusion

Denne artikel demonstrerer, hvordan Spring Security deaktiverer HTTP-caching som standard og forklarer, at dette er fordi vi ikke ønsker at cache sikre ressourcer. Vi har også set, hvordan vi kan deaktivere eller ændre denne adfærd, som vi finder det passende.

Implementeringen af ​​alle disse eksempler og kodestykker findes i GitHub-projektet - dette er et Maven-projekt, så det skal være let at importere og køre, som det er.