Spring Security - biztonság nincs, nincs szűrő, hozzáférési engedélyAll

1. Áttekintés

A Spring Security számos mechanizmust biztosít a kérésminta nem biztonságosként vagy minden hozzáférést engedélyező konfigurálásához. Ezektől a mechanizmusoktól függően - ez azt jelentheti, hogy egyáltalán nem futtatja a biztonsági szűrő láncot ezen az úton, vagy futtatja a szűrő láncot, és engedélyezi a hozzáférést.

2. hozzáférés = ”engedélyAll”

Egy elem a hozzáférés = ”engedélyAll” úgy konfigurálja az engedélyezést, hogy az összes kérés legyen megengedett az adott úton:

Vagy Java konfiguráción keresztül:

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

Ez megvalósul a biztonsági szűrők letiltása nélkül - ezek továbbra is futnak, így a Spring Security-hez kapcsolódó bármely funkció továbbra is elérhető lesz.

3. szűrők = ”nincs”

Ez egy tavasz előtti 3.1-es szolgáltatás, amely már volt 3.1 tavasszal elavult és kicserélték.

A szűrők attribútum letiltja a Spring Security szűrő láncot teljesen az adott kérési útvonalon:

Ez problémákat okozhat, amikor a kérés feldolgozása a Spring Security bizonyos funkcióit igényli.

Mivel ez egy elavult szolgáltatás, a Spring 3.0-nál újabb verziók, ezért a Spring 3.1 használatával futásidejű kivételt eredményez az indításkor:

SEVERE: A kontextus inicializálása sikertelen org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Konfigurációs probléma: A "filters = 'none'" használata már nem támogatott. Adjon meg egy külön elemet a kizárandó mintához, és használja a "security = 'none'" attribútumot. Sértő erőforrás: osztályútvonal erőforrás [webSecurityConfig.xml] az o.s.b.f.p.FailFastProblemReporter.error (FailFastProblemReporter.java:68)

4. biztonság = ”nincs”

Amint azt a fenti hibaüzenetben láttuk, a 3.1 tavasz helyettesíti szűrők = ”nincs” új kifejezéssel - biztonság = ”nincs”.

A hatókör is megváltozott - ez a továbbiakban nincs meghatározva elemszint. Ehelyett a 3.1 tavasz lehetővé teszi többszörös elemek meghatározandó - mindegyik saját biztonsági szűrő lánc konfigurációval. Tehát az új biztonsági attribútum most a elemszint.

A gyakorlatban ez így fog kinézni:

Vagy Java konfigurációval:

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

A régi helyett:

Hasonló szűrők = ”nincs”, ez szintén teljesen letiltja a biztonsági szűrő láncot az adott kérési útvonalon - így amikor a kérelmet az alkalmazás kezeli, a Spring Security funkciók nem lesznek elérhetők.

Ez nem okoz problémát a fenti példákkal, amelyek főleg foglalkoznak statikus erőforrások kiszolgálása - ahol tényleges feldolgozásra nem kerül sor. Ha azonban a kérést valamilyen módon programszerűen kezelik - akkor a biztonsági funkciók, mint pl igényel-csatorna, az aktuális felhasználó elérése vagy a biztonságos módszerek hívása nem lesz elérhető.

Ugyanezen okból nincs értelme további attribútumokat megadni az már konfigurált elem biztonság = ”nincs” mert ez a kérési útvonal nem biztonságos, és az attribútumokat egyszerűen figyelmen kívül hagyják.

Alternatív megoldásként hozzáférés = 'IS_AUTHENTICATED_ANONYMOUSLY' névtelen hozzáférés engedélyezésére használható.

5. Figyelmeztetések biztonság = ”nincs”

Többszörös használata esetén elemek, némelyikük konfigurálva van biztonság = ”nincs”, ne feledje, hogy ezeknek az elemeknek a meghatározási sorrendje fontos. Azt akarjuk, hogy a konkrét utak először követték az egyetemes mintát a legvégén.

Vegye figyelembe azt is, hogy ha egy elem nem ad meg mintát, akkor alapértelmezés szerint az univerzális egyezési mintához - “/ **” - kapcsolódik, tehát ennek az elemnek ismét utolsónak kell lennie. Ha az elemek sorrendje nem megfelelő, akkor a a biztonsági szűrő lánc létrehozása meghiúsul:

Okozta: java.lang.IllegalArgumentException: Az univerzális egyezési mintát ('/ **') a szűrőlánc többi mintája előtt definiálják, ami figyelmen kívül hagyja őket. Kérjük, ellenőrizze a sorrendet a névtérben vagy a FilterChainProxy babkonfigurációban az o.s.s.c.h.DefaultFilterChainValidator.checkPathOrder (DefaultFilterChainValidator.java:49) címen: o.s.s.c.h.DefaultFilterChainValidainValidain.valid

6. Következtetés

Ez a cikk azokat a lehetőségeket tárgyalja, amelyek lehetővé teszik a hozzáférést egy útvonalhoz a Spring Security alkalmazással - a különbségekre összpontosítva szűrők = ”nincs”, biztonság = ”nincs” és a hozzáférés = ”engedélyAll”.

Szokás szerint a példák elérhetők a GitHub oldalon.