streamalism.org

1. Oversikt

Spring Security tilbyr flere mekanismer for å konfigurere et forespørselsmønster som usikret eller tillate all tilgang. Avhengig av hver av disse mekanismene - dette kan enten bety at du ikke kjører sikkerhetsfilterkjeden på den banen i det hele tatt, eller kjører filterkjeden og gir tilgang.

2. tilgang = ”permitAll”

Sette opp en element med tilgang = ”permitAll” vil konfigurere autorisasjonen slik at alle forespørsler er tillatt på den aktuelle banen:

Eller via Java-konfigurasjon:

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

Dette oppnås uten å deaktivere sikkerhetsfiltrene - disse kjøres fortsatt, så all vårsikkerhetsrelatert funksjonalitet vil fremdeles være tilgjengelig.

3. filtre = ”ingen”

Dette er en funksjon som har vært før våren 3.1 utfaset og erstattet våren 3.1.

De filtre attributt deaktiverer Spring Security-filterkjeden helt på den aktuelle forespørselsbanen:

Dette kan føre til problemer når behandlingen av forespørselen vil kreve funksjonalitet i Spring Security.

Siden dette er en utdatert funksjon Spring-versjoner som er nyere enn 3.0, vil bruk av den med Spring 3.1 resultere i et runtime-unntak ved oppstart:

ALVORLIG: Kontekstinitialisering mislyktes org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Konfigurasjonsproblem: Bruken av "filters = 'none'" støttes ikke lenger. Definer et eget element for mønsteret du vil ekskludere, og bruk attributtet "sikkerhet = 'ingen'". Krenkende ressurs: klassebasressurs [webSecurityConfig.xml] på o.s.b.f.p.FailFastProblemReporter.error (FailFastProblemReporter.java:68)

4. sikkerhet = ”ingen”

Som vi så i feilmeldingen ovenfor, erstatter Spring 3.1 filtre = ”ingen” med et nytt uttrykk - sikkerhet = ”ingen”.

Omfanget har også endret seg - dette er ikke lenger spesifisert på elementnivå. I stedet tillater våren 3.1 flere elementer som skal defineres - hver med sin egen sikkerhetsfilterkjedekonfigurasjon. Og så, den nye sikkerhetsattributtet hører nå hjemme på elementnivå.

I praksis vil dette se ut som:

Eller med Java-konfigurasjon:

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

I stedet for det gamle:

Lik filtre = ”ingen”, vil dette også deaktivere sikkerhetsfilterkjeden for den forespørselsbanen - så når forespørselen håndteres i applikasjonen, vil ikke Spring Security-funksjoner være tilgjengelige.

Dette er ikke et problem for eksemplene ovenfor, som hovedsakelig tar for seg serverer statiske ressurser - der ingen faktisk behandling foregår. Imidlertid, hvis forespørselen håndteres programmatisk på en eller annen måte - så vil sikkerhetsfunksjoner som krever-kanal, tilgang til den nåværende brukeren eller ringe sikre metoder vil ikke være tilgjengelig.

Av samme grunn er det ikke noe poeng å spesifisere flere attributter på en element som allerede er konfigurert med sikkerhet = ”ingen” fordi forespørselsbanen er usikret og attributtene rett og slett blir ignorert.

Alternativt access = 'IS_AUTHENTICATED_ANONYMOUSLY' kan brukes til å tillate anonym tilgang.

5. forbehold for sikkerhet = ”ingen”

Når du bruker flere elementer, noen konfigurert med sikkerhet = ”ingen”, husk at rekkefølgen som disse elementene er definert i er viktig. Vi ønsker å ha det spesifikke stier først, fulgte det universelle mønsteret helt på slutten.

Vær også oppmerksom på at hvis en element angir ikke et mønster, som standard, som tilordnes til det universelle samsvarsmønsteret - “/ **” - så igjen, dette elementet må være sist. Hvis rekkefølgen på elementene ikke er riktig, vil etableringen av sikkerhetsfilterkjeden vil mislykkes:

Forårsaket av: java.lang.IllegalArgumentException: Et universelt matchmønster ('/ **') er definert før andre mønstre i filterkjeden, og får dem til å bli ignorert. Vennligst sjekk bestillingen i navneområdet eller FilterChainProxy-bønnekonfigurasjonen på o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder (DefaultFilterChainValidator.java:49) på o.s.s.c.h.DefaultFilterChainValidator.validate (DefaultFilterChainValidator.java)

6. Konklusjon

Denne artikkelen diskuterer alternativene for å gi tilgang til en bane med Spring Security - med fokus på forskjellene mellom filters = ”none”, security = ”none” og access = ”permitAll”.

Som vanlig er eksemplene tilgjengelige på GitHub.