streamalism.org

1. Oversigt

Spring Security giver flere mekanismer til at konfigurere et anmodningsmønster som usikret eller tillade al adgang. Afhængigt af hver af disse mekanismer - kan dette enten betyde, at du slet ikke kører sikkerhedsfilterkæden på den sti eller kører filterkæden og giver adgang.

2. adgang = ”permitAll”

Opsætning af en element med adgang = ”permitAll” konfigurerer autorisationen, så alle anmodninger er tilladt på den særlige vej:

Eller via Java-konfiguration:

http.authorizeRequests (). antMatchers ("/ login *"). permitAll ();

Dette opnås uden at deaktivere sikkerhedsfiltrene - disse kører stadig, så enhver Spring Security-relateret funktionalitet vil stadig være tilgængelig.

3. filtre = ”ingen”

Dette er en funktion, der har været før foråret 3.1 forældet og erstattet i foråret 3.1.

Det filtre attribut deaktiverer Spring Security-filterkæden helt på den pågældende anmodningssti:

Dette kan medføre problemer, når behandlingen af ​​anmodningen kræver en vis funktionalitet i Spring Security.

Da dette er en forældet funktion Spring-versioner, der er nyere end 3.0, vil brug af den med Spring 3.1 resultere i en runtime-undtagelse ved opstart:

SVERE: Kontextinitialisering mislykkedes org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Konfigurationsproblem: Brug af "filters = 'none'" understøttes ikke længere. Definer et separat element til det mønster, du vil ekskludere, og brug attributten "sikkerhed = 'ingen'". Stødende ressource: klasse stieressource [webSecurityConfig.xml] på o.s.b.f.p.FailFastProblemReporter.error (FailFastProblemReporter.java:68)

4. sikkerhed = ”ingen”

Som vi så i fejlmeddelelsen ovenfor, erstatter Spring 3.1 filtre = ”ingen” med et nyt udtryk - sikkerhed = ”ingen”.

Omfanget er også ændret - dette er ikke længere specificeret på element niveau. I stedet tillader Spring 3.1 mange elementer der skal defineres - hver med sin egen sikkerhedsfilterkædekonfiguration. Og så hører den nye sikkerhedsattribut nu til på element niveau.

I praksis vil dette se ud som:

Eller med Java-konfiguration:

web.ignoring (). antMatchers ("/ resources / **");

I stedet for det gamle:

Svarende til filtre = ”ingen”, dette vil også deaktivere sikkerhedsfilterkæden for den anmodningssti - så når anmodningen håndteres i applikationen, er Spring Security-funktioner ikke tilgængelige.

Dette er ikke et problem for eksemplerne ovenfor, som hovedsagelig beskæftiger sig med betjener statiske ressourcer - hvor ingen faktisk behandling finder sted. Men hvis anmodningen håndteres programmatisk på en eller anden måde - så er sikkerhedsfunktioner såsom kræver-kanal, adgang til den aktuelle bruger eller opkaldssikrede metoder vil ikke være tilgængelig.

Af samme grund er der ingen mening med at specificere yderligere attributter på en element, der allerede er konfigureret med sikkerhed = ”ingen” fordi anmodningsstien ikke er sikret, og attributterne simpelthen ignoreres.

Alternativt adgang = 'IS_AUTHENTICATED_ANONYMOUSLY' kan bruges til at tillade anonym adgang.

5. forbehold for sikkerhed = ”ingen”

Når du bruger flere elementer, nogle konfigureret med sikkerhed = ”ingen”, husk at rækkefølgen, i hvilken disse elementer er defineret, er vigtig. Vi ønsker at have det specifikke stier først, fulgte det universelle mønster i slutningen.

Bemærk også, at hvis en element angiver ikke et mønster, så kort som standard, at det universelle matchmønster - “/ **” - så igen, dette element skal være sidst. Hvis rækkefølgen af ​​elementerne ikke er korrekt, oprettelsen af ​​sikkerhedsfilterkæden mislykkes:

Forårsaget af: java.lang.IllegalArgumentException: Et universelt matchmønster ('/ **') defineres før andre mønstre i filterkæden, hvilket får dem til at blive ignoreret. Tjek venligst rækkefølgen i dit navneområde eller FilterChainProxy-bønnekonfiguration på o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder (DefaultFilterChainValidator.java:49) på o.s.s.c.h.DefaultFilterChainValidator.validate (DefaultFilterChainValidator.jalidator.java)

6. Konklusion

Denne artikel diskuterer mulighederne for at give adgang til en sti med Spring Security - med fokus på forskellene mellem filtre = ”none”, sikkerhed = ”none” og access = ”permitAll”.

Som sædvanligt er eksemplerne tilgængelige på GitHub.