streamalism.org

1. Oversigt

Denne vejledning viser, hvordan du opsætter, konfigurerer og tilpasser Grundlæggende godkendelse med foråret. Vi skal bygge oven på det enkle Spring MVC-eksempel og sikre brugergrænsefladen til MVC-applikationen med Basic Auth-mekanismen fra Spring Security.

2. Spring Security Configuration

Vi kan konfigurere Spring Security ved hjælp af Java config:

@Configuration @EnableWebSecurity offentlig klasse CustomWebSecurityConfigurerAdapter udvider WebSecurityConfigurerAdapter {@Autowired private MyBasicAuthenticationEntryPoint authenticationEntryPoint; @Autowired public void configureGlobal (AuthenticationManagerBuilder auth) kaster undtagelse {auth.inMemoryAuthentication () .withUser ("user1"). Adgangskode (passwordEncoder (). Kodning ("user1Pass")). Autoriteter ("ROLE_USER"); } @ Override beskyttet ugyldig konfiguration (HttpSecurity http) kaster Undtagelse {http.authorizeRequests () .antMatchers ("/ securityNone"). PermitAll () .anyRequest (). Godkendt () .and () .httpBasic () .authenticationEntryPoint (authenticationEntryPoint) ); http.addFilterAfter (ny CustomFilter (), BasicAuthenticationFilter.class); } @Bean public PasswordEncoder passwordEncoder () {returner ny BCryptPasswordEncoder (); }}

Her bruger vi httpBasic () element til at definere grundlæggende godkendelse inden i konfigurer () metode til en klasse, der strækker sig WebSecurityConfigurerAdapter.

Det samme kunne også opnås ved hjælp af XML:

Hvad der er relevant her er element inde i hoveddelen element i konfigurationen - dette er nok til at aktivere grundlæggende godkendelse for hele applikationen. Authentication Manager er ikke fokus for denne tutorial, så vi bruger en in-memory manager med brugeren og adgangskoden defineret i almindelig tekst.

Det web.xml af webapplikationen, der muliggør Spring Security, er allerede blevet diskuteret i Spring Logout-selvstudiet.

3. Forbruge den sikrede applikation

Det krølle kommando er vores go-to-værktøj til forbrug af den sikrede applikation.

Lad os først prøve at anmode om /hjemmeside.html uden at give nogen sikkerhedsoplysninger:

curl -i // localhost: 8080 / spring-security-rest-basic-auth / api / foos / 1

Vi får tilbage det forventede 401 Uautoriseret og godkendelsesudfordringen:

HTTP / 1.1 401 Uautoriseret server: Apache-Coyote / 1.1 Set-cookie: JSESSIONID = E5A8D3C16B65A0A007CFAACAEEE6916B; Sti = / spring-security-mvc-basic-auth /; HttpOnly WWW-Authenticate: Basic realm = "Spring Security Application" Content-Type: text / html; charset = utf-8 Content-Length: 1061 Date: Wed, 29 May 2013 15:14:08 GMT

Browseren fortolker denne udfordring og beder os om legitimationsoplysninger med en simpel dialog, men da vi bruger krølle, dette er ikke tilfældet.

Lad os nu anmode om den samme ressource - hjemmesiden - men give legitimationsoplysninger for at få adgang til det også:

krølle -i --brugerbruger1: bruger1Pass // localhost: 8080 / fjeder-sikkerhed-hvile-grundlæggende-autent / api / foos / 1

Nu er svaret fra serveren 200 OK sammen med en Cookie:

HTTP / 1.1 200 OK Server: Apache-Coyote / 1.1 Set-cookie: JSESSIONID = 301225C7AE7C74B0892887389996785D; Sti = / spring-security-mvc-basic-auth /; HttpOnly Content-Type: text / html; charset = ISO-8859-1 Content-Language: en-US Content-Length: 90 Date: Wed, 29 May 2013 15:19:38 GMT

Fra browseren kan applikationen forbruges normalt - den eneste forskel er, at en login-side ikke længere er et hårdt krav, da alle browsere understøtter grundlæggende godkendelse og bruger en dialog til at bede brugeren om legitimationsoplysninger.

4. Yderligere konfiguration - than indgangssted

Som standard er BasicAuthenticationEntryPoint tilvejebragt af Spring Security returnerer en hel side til en 401 Uautoriseret svar tilbage til klienten. Denne HTML-repræsentation af fejlen gengives godt i en browser, men den er ikke velegnet til andre scenarier, såsom en REST API, hvor en json-repræsentation kan foretrækkes.

Navneområdet er også fleksibelt til dette nye krav - for at løse dette - indgangsstedet kan tilsidesættes:

Det nye indgangspunkt er defineret som en standardbønne:

@Komponent offentlig klasse MyBasicAuthenticationEntryPoint udvider BasicAuthenticationEntryPoint {@Override public void start (HttpServletRequest anmodning, HttpServletResponse respons, AuthenticationException authEx) kaster IOException, ServletException {respons.addHeader ("WWW") "" respons.setStatus (HttpServletResponse.SC_UNAUTHORIZED); PrintWriter-forfatter = respons.getWriter (); writer.println ("HTTP Status 401 -" + authEx.getMessage ()); } @ Override offentlig ugyldighed efterPropertiesSet () kaster undtagelse {setRealmName ("Baeldung"); super.afterPropertiesSet (); }}

Ved at skrive direkte til HTTP-svaret har vi nu fuld kontrol over responsorganets format.

5. Maven-afhængighederne

Maven-afhængighederne for Spring Security er blevet diskuteret før i artiklen om Spring Security with Maven - vi har brug for begge dele fjeder-sikkerhed-web og spring-security-config tilgængelig ved kørsel.

6. Konklusion

I dette eksempel sikrede vi en MVC-applikation med Spring Security og Basic Authentication. Vi diskuterede XML-konfigurationen, og vi forbrugte applikationen med enkle krøllekommandoer. Til sidst tog kontrol over det nøjagtige format for fejlmeddelelser - flyttede fra standard HTML-fejlsiden til et brugerdefineret tekst- eller JSON-format.

Den fulde implementering af denne vejledning kan findes i GitHub-projektet - dette er et Maven-baseret projekt, så det skal være let at importere og køre som det er.

Når projektet kører lokalt, kan du få adgang til HTML-eksemplet på:

// localhost: 8080 / spring-security-rest-basic-auth / api / foos / 1.