To login sider med Spring Security

1. Introduktion

I denne vejledning vil vi se, hvordan vi kan konfigurer Spring Security til at arbejde med to forskellige login-sider ved hjælp af to forskellige Spring Security http elementer i konfigurationen.

2. Konfiguration af 2 Http-elementer

En af de situationer, hvor vi muligvis har brug for to login-sider, er når vi har en side til administratorer af en applikation og en anden side for normale brugere.

Vi vil konfigurer to http elementer der vil blive differentieret af URL-mønsteret, der er knyttet til hver:

  • /bruger* for sider, der har brug for en normal brugergodkendelse for at få adgang
  • / admin * for sider, som en administrator har adgang til

Hver http element har en anden login-side og en anden login-behandlings-URL.

For at konfigurere to forskellige http elementer, lad os oprette to statiske klasser, der er kommenteret med @Konfiguration der udvider WebSecurityConfigurerAdapter.

Begge placeres inde i en regelmæssig @Konfiguration klasse:

@Configuration @EnableWebSecurity offentlig klasse SecurityConfig {...}

Lad os definere WebSecurityConfigurerAdapter til “ADMIN” brugere:

@Configuration @Order (1) offentlig statisk klasse App1ConfigurationAdapter udvider WebSecurityConfigurerAdapter {public App1ConfigurationAdapter () {super (); } @ Override-beskyttet ugyldig konfiguration (HttpSecurity http) kaster undtagelse {http.antMatcher ("/ admin *") .authorizeRequests () .anyRequest () .hasRole ("ADMIN"). Og () .formLogin () .loginPage (" / loginAdmin ") .loginProcessingUrl (" / admin_login ") .failureUrl (" / loginAdmin? error = loginError "). defaultSuccessUrl (" / adminPage "). og () .logout () .logoutUrl (" / admin_logout ") .logoutSuccessUr ("/ protectedLinks") .deleteCookies ("JSESSIONID"). og () .exceptionHandling () .accessDeniedPage ("/ 403"). og () .csrf (). deaktiver (); }}

Lad os nu definere WebSecurityConfigurerAdapter til normale brugere:

@Configuration @Order (2) offentlig statisk klasse App2ConfigurationAdapter udvider WebSecurityConfigurerAdapter {public App2ConfigurationAdapter () {super (); } beskyttet ugyldig konfiguration (HttpSecurity http) kaster undtagelse {http.antMatcher ("/ bruger *") .authorizeRequests () .anyRequest () .hasRole ("USER") .og () .formLogin () .loginPage ("/ loginUser) ") .loginProcessingUrl (" / user_login ") .failureUrl (" / loginUser? error = loginError "). defaultSuccessUrl (" / userPage "). and () .logout () .logoutUrl (" / user_logout ") .logoutSuccessUrl (" / protectedLinks ") .deleteCookies (" JSESSIONID "). og () .exceptionHandling () .accessDeniedPage (" / 403 "). og () .csrf (). deaktiver (); }}

Bemærk, at ved at placere @Bestille bemærkning for hver statiske klasse, vi specificerer rækkefølgen, i hvilken de to klasser vil blive betragtet ud fra det mønster, der matcher, når der anmodes om en URL.

To konfigurationsklasser kan ikke have samme rækkefølge.

3. Brugerdefinerede login-sider

Vi opretter vores egne brugerdefinerede login-sider til hver type bruger. For administratorbrugeren har loginformularen en “Bruger_login” handling, som defineret i konfigurationen:

Bruger login side

Bruger:
Adgangskode:

Administrators login-side er ens, bortset fra at formularen har en handling på “Admin_login” som i java-konfigurationen.

4. Godkendelseskonfiguration

Nu skal vi konfigurer godkendelse til vores applikation. Lad os se på to måder at opnå dette på - den ene ved hjælp af en fælles kilde til brugergodkendelse og den anden ved hjælp af to separate kilder.

4.1. Brug af en almindelig brugergodkendelseskilde

Hvis begge login-sider deler en fælles kilde til godkendelse af brugere, kan du oprette en enkelt bønne af typen UserDetailsService der håndterer godkendelsen.

Lad os demonstrere dette scenario ved hjælp af en InMemoryUserDetailsManager der definerer to brugere - en med rollen som "BRUGER" og en med en rolle som “ADMIN”:

@Bean offentlig UserDetailsService userDetailsService () kaster undtagelse {InMemoryUserDetailsManager manager = ny InMemoryUserDetailsManager (); manager.createUser (User .withUsername ("user") .password (encoder (). encode ("userPass")) .roles ("USER") .build ()); manager.createUser (User .withUsername ("admin") .password (encoder (). encode ("adminPass")) .roles ("ADMIN") .build ()); returleder; } @Bean offentlig statisk PasswordEncoder-indkoder () {returner ny BCryptPasswordEncoder (); }

4.2. Brug af to forskellige brugergodkendelseskilder

Hvis du har forskellige kilder til brugergodkendelse - en til administratorer og en til normale brugere - kan du konfigurere en AuthenticationManagerBuilder inde i hver statisk @Konfiguration klasse. Lad os se på et eksempel på en godkendelsesadministrator for en “ADMIN” bruger:

@Configuration @Order (1) offentlig statisk klasse App1ConfigurationAdapter udvider WebSecurityConfigurerAdapter {@Override beskyttet ugyldig konfiguration (AuthenticationManagerBuilder auth) kaster Exception {auth.inMemoryAuthentication () .withUser ("admin") .password (encoder () "kode. )) .roles ("ADMIN"); }}

I dette tilfælde er UserDetailsService bønne fra det foregående afsnit vil ikke længere blive brugt.

6. Konklusion

I denne hurtige vejledning har vi vist, hvordan man implementerer to forskellige login-sider i den samme Spring Security-applikation.

Den komplette kode til denne artikel kan findes i GitHub-projektet.

Når du kører applikationen, kan du få adgang til eksemplerne ovenfor på / protectedLinks URI.


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