Ben Alex wrote:
I have been considering the DaoAuthenticationProvider caching approach and think we should change it. At present the cache depends on a DaoAuthenticationToken being present in a user session. The problem with this is BASIC authentication is stateless, meaning the DaoAuthenticationToken is never available from a HttpSession, which in turns results in AuthenticationDao being repeatedly called. This is not only a performance issue, but if you're relying on the newly added ApplicationEvent functionality, your authentication log contains an "authentication success" message for each and every web request. BASIC authentication is hardly an exotic usage scenario, as it's central to remoting protocols like Burlap, and often is used as the authentication approach by third party classes (eg Jakarta Slide).
As a solution, I'd propose we provide a new UserCache interface with two methods, getUserFromCache(String username) and putUserInCache(String username, User user). A basic EhBasedUserCache implementation will be provided, as we're already using it for caching with CAS. Cache settings (time-to-live etc) will be set against the relevant UserCache implementation. DaoAuthenticationProvider will default to using EhBasedUserCache, to save unnecessary XML declarations.
Do people agree with this change? If so, should we continue to offer a DaoAuthenticationToken that should be placed into the HttpSession, or should we remove it? One advantage of keeping the DaoAuthenticationToken is the UserCache becomes a "second level" cache, only being queried when the DaoAuthenticationToken (kept in the HttpSession) has expired. One strong advantage of removing the DaoAuthenticationToken is there would be only one object responsible for caching, thus enabling a UserCache implementation to provide removeFromCache(String username) methods that can be called by administrative components of an application. I tend to lean towards removing it, but I'm interested in other people's opinions as always.
Thanks
Ben
Ben,
Do you want to replace the use of the token with Basic authentication only, or completely? I presume the latter?
I don't have very strong feelings either way with the two alternative, although I guess the remove allows more control in terms of locking out people before the ttl of the token would do it, on a user info change...
Colin
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
