Na minulých projektech jsme používali Acegi security se spoustou vlastních doplňků a vychytávek. Teď začínáme psát nový projekt a tak jsme si řekli, že je už čas se posunout dát a začít použít Spring security (jeden z důvodů byla podpora NTLM ve Spring security, ale o tom budu psát v dalších příspěvku).
V tomto článku bych rád uvedl moje zkušenosti s touto migrace. Základní naše konfigurace vypadala asi jako ta uvedená v článku Ukázka konfigurace Acegi security plus jsme si vytvořili tzv. bezpečností modul, který obsahuje různá rozšíření, které standardně v Acegi implementovány nejsou (např. zablokování účtu po třech špatných přihlášeních, kontrola na existenci rolí při přihlašování apod.).
Vzal jsem tedy konfiguraci a pár stránek ze starého projektu a nasadil do nového. Musel jsem provést následující úpravy:
- přejmenovat balíky org.acegisecurity na org.springframework.security. Takže když jsem měl v konfiguraci org.acegisecurity.ui.ExceptionTranslationFilter, tak jsem to musel změnit na org.springframework.security.ui.ExceptionTranslationFilter.
- přejmenovat některé statické proměnné, např. AbstractProcessingFilter.ACEGI_SECURITY_LAST_EXCEPTION_KEY na AbstractProcessingFilter.SPRING_SECURITY_LAST_EXCEPTION_KEY nebo AuthenticationProcessingFilter.ACEGI_SECURITY_LAST_USERNAME_KEY na AuthenticationProcessingFilter.SPRING_SECURITY_LAST_USERNAME_KEY. Tyto proměnné nepoužívám přímo v konfiguraci, ale již v rámci našeho kódu.
- přejmenovat URL pro odhlášení z j_acegi_logout na j_spring_security_logout.
- přejmenovat URL pro zpracování přihlašovacího formuláře z j_acegi_security_check na j_spring_security_check.
A to je všechno, vše bez problémů. Zatím jsem migroval vše kromě naší knihovny, ale tam již žádné problémy neočekávám. Pouze bude nutné všechny použité třídy z Acegi přejmenovat na Spring security.
Jediné co mě překvapilo je, že jsem nikde na stránkách Springu, ani v dokumentaci Spring security nenašel návod k migraci.
Zdroje informací:
Příspěvky
3 komentáře:
Mate nejake skusenosti s novymi featurami vyplyvajucimi z pouzivania namespaceov v aplikacnych kontextoch Springu? Hovori sa, ze konfiguracia bezpecnosti v Spring Security sa zjednodusila - miestami z desiatich beanov na jeden riadok.
Přesně to jsem teď taky řešil :).
Zkusím na to odpovědět otázkou - proč Spring security začal také používat namespaci? Důvodů je asi více, mě napadá hlavně tento - konfigurace Spring security byla celkem složitá a na první pohled možná až odstrašující. To teď nemyslím žádné složitosti, ale prostě základní potřeby autentikace a autorizace jednoduché webové aplikace. Pro tyto jednoduché případy je úspora kódu evidentní, protože stačí napsat <http auto-config='true'> a většina se toho nastaví automaticky. Když chci něco udělat jinak, mám možnost, v tomto směru namespaci nejsou nijak omezující - si myslím, nemám přímo zkušenost.
Tedy žádný problém, ale i přesto jsem zatím namespaci nezačal používat. Proč? Jednak již celkem všechny ty třídy znám, takže konfigurace mi problémy žádné nedělá. Dále snad ještě nikdy jsme nepoužívali nějakou základní konfiguraci - vždy to máme "trochu" složitější, vždy máme nějaký ten svůj kód. To samozřejmě je možné i s namespaci, ale ta úspora již není přeci jen tak významná. Poslední důvod je, že mám obecný blok k věcem, které "se dějí automaticky, a o kterých přesně nevím". Raději si to tedy budu skládat přesně z jednotlivých tříd, než používat nějaké "magické" namespaci.
Zatím jsem se tedy rozhodl namespaci vynechat a uvidím, co ostatní kolegové v týmu. Pokud budu cítit, že to bude pro ně lepší, že to budou chtít, tak to přepíšu do namespaců. Já jsem obecně v těchto ohledech spíše konzervativní - spíše XML než anotace, spíše přímo třídy místo namespaců.
* http://www.phpguru.cz/clanky/autentizace
* http://interval.cz/clanky/hrichy-pro-sileneho-korektora-autentizace-autentikace-nebo-autentifikace/
Okomentovat