Endring av vårmodellparametere med Handler Interceptor

1. Introduksjon

I denne opplæringen skal vi fokusere på Spring MVC HandlerInterceptor. Mer spesifikt vil vi endre Spring MVCs modellparametere før og etter behandling av en forespørsel.

Hvis du vil lese om HandlerInterceptor's grunnleggende, sjekk ut denne artikkelen.

2. Maven-avhengigheter

For å bruke Avskjærere, må du ta med følgende avsnitt i a avhengigheter delen av din pom.xml fil:

 org.springframework spring-web 5.2.8.RELEASE 

Siste versjon finner du her.

Denne avhengigheten dekker bare Spring Web, så ikke glem å legge til spring-core og vår-kontekst for en fullverdig webapplikasjon og et loggbibliotek etter eget valg.

3. Egendefinert implementering

En av brukssakene til HandlerInterceptor legger til vanlige / brukerspesifikke parametere i en modell, som vil være tilgjengelig i hver genererte visning.

I vårt eksempel vil vi bruke tilpasset interceptorimplementering for å legge til logget brukerens brukernavn til modellparametere. I mer komplekse systemer kan vi legge til mer spesifikk informasjon som: brukeravatarbane, brukerplassering, etc.

La oss begynne med å definere det nye Interceptor klasse:

offentlig klasse UserInterceptor utvider HandlerInterceptorAdapter {private static Logger log = LoggerFactory.getLogger (UserInterceptor.class); ...}

Vi forlenger HandlerInterceptorAdapter, som vi bare vil implementere preHandle () og postHandle () metoder.

Som vi nevnte tidligere, vil vi legge til logget brukernavn til en modell. Først og fremst må vi sjekke om en bruker er logget inn. Vi kan få denne informasjonen ved å sjekke SecurityContextHolder:

offentlig statisk boolsk isUserLogged () {prøv {return! SecurityContextHolder.getContext (). getAuthentication () .getName (). er lik ("anonymousUser"); } fange (Unntak e) {return false; }}

Når en HttpSession er etablert, men ingen er logget på, et brukernavn i vårsikkerhetssammenheng tilsvarer anonym bruker. Deretter fortsetter vi med implementering av preHandle ():

3.1. Metode preHandle ()

Før vi behandler en forespørsel, har vi ikke tilgang til modellparametere. For å legge til brukernavn, må vi bruke HttpSession for å stille inn parametere:

@Override offentlig boolsk preHandle (HttpServletRequest-forespørsel, HttpServletResponse-respons, Objektobjekt) kaster Unntak {if (isUserLogged ()) {addToModelUserDetails (request.getSession ()); } returner sant; }

Dette er avgjørende hvis vi bruker noe av denne informasjonen før vi behandler en forespørsel. Som vi ser, sjekker vi om en bruker er logget inn, og legger deretter til parametere i forespørselen vår ved å få sin økt:

privat ugyldig addToModelUserDetails (HttpSession-økt) {log.info ("================ addToModelUserDetails ======================= ==== "); Streng logget brukernavn = SecurityContextHolder.getContext (). GetAuthentication (). GetName (); session.setAttribute ("brukernavn", logget brukernavn); log.info ("bruker (" + logget brukernavn + ") økt:" + økt); log.info ("================ addToModelUserDetails ==========================="); }

Vi brukte SecurityContextHolder for å oppnå logget brukernavn. Du kan overstyre vårsikkerhet UserDetails implementering for å få e-post i stedet for et standard brukernavn.

3.2. Metode sostHandle ()

Etter å ha behandlet en forespørsel er modellparametrene våre tilgjengelige, så vi kan få tilgang til dem for å endre verdier eller legge til nye. For å gjøre det bruker vi det overstyrte postHandle () metode:

@Override public void postHandle (HttpServletRequest req, HttpServletResponse res, Object o, ModelAndView model) kaster Unntak {if (model! = Null &&! IsRedirectView (model)) {if (isUserLogged ()) {addToModelUserDetails (model); }}}

La oss ta en titt på implementeringsdetaljene.

Først og fremst er det bedre å sjekke om modellen ikke er det null. Det vil hindre oss i å møte et NullPointerException.

Videre kan vi sjekke om en Utsikt er ikke en forekomst av omdirigeringUtsikt.

Det er ikke nødvendig å legge til / endre parametere etter at forespørselen er håndtert og deretter omdirigert, som umiddelbart vil den nye kontrolleren utføre håndtering igjen. For å sjekke om visningen blir omdirigert, introduserer vi følgende metode:

offentlig statisk boolsk isRedirectView (ModelAndView mv) {String viewName = mv.getViewName (); hvis (viewName.startsWith ("redirect: /")) {return true; } Vis visning = mv.getView (); returner (visning! = null && vis forekomst av SmartView && ((SmartView) -visning) .isRedirectView ()); }

Til slutt sjekker vi igjen om en bruker er logget, og hvis ja, legger vi til parametere til vårmodellen:

privat tomrom addToModelUserDetails (ModelAndView-modell) {log.info ("================ addToModelUserDetails ======================== ==== "); Streng logget brukernavn = SecurityContextHolder.getContext () .getAuthentication (). GetName (); model.addObject ("logget brukernavn", logget brukernavn); log.trace ("session:" + model.getModel ()); log.info ("================ addToModelUserDetails ==========================="); }

Vær oppmerksom på at logging er veldig viktig, siden denne logikken fungerer "bak kulissene" i applikasjonen vår. Det er lett å glemme at vi endrer noen modellparametere på hver Utsikt uten å logge den ordentlig.

4. Konfigurasjon

For å legge til det nyopprettede Interceptor i vårkonfigurasjon, må vi overstyre addInterceptors () metode inni WebConfig klasse som implementerer WebMvcConfigurer:

@Override public void addInterceptors (InterceptorRegistry registry) {registry.addInterceptor (new UserInterceptor ()); }

Vi kan oppnå den samme konfigurasjonen ved å redigere vår XML Spring-konfigurasjonsfil:

Fra dette øyeblikket kan vi få tilgang til alle brukerrelaterte parametere på alle genererte visninger.

Vær oppmerksom på, hvis flere Spring Avskjærere er konfigurert, er preHandle () metoden utføres i rekkefølgen av konfigurasjonen mens postHandle () og afterCompletion () metoder påkalles i omvendt rekkefølge.

5. Konklusjon

Denne opplæringen presenterer avlyttende nettforespørsler ved hjelp av Spring MVCs HandlerInterceptor for å gi brukerinformasjon.

I dette spesielle eksemplet fokuserte vi på å legge til loggede brukerdetaljer i webapplikasjonen vår for å modellere parametere. Du kan utvide dette HandlerInterceptor implementering ved å legge til mer detaljert informasjon.

Alle eksempler og konfigurasjoner er tilgjengelige her på GitHub.

5.1. Artikler i serien

Alle artiklene i serien:

  • Introduksjon til Spring MVC Handler Interceptors
  • Endring av vårmodellparametere med Handler Interceptor (denne)

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