On Fri, May 13, 2011 at 6:10 PM, juminoz <[email protected]> wrote:
> So you basically never logout and just let the session expires? I actually > just found out that my session never actually expires even with timeout for > some reasons while I was testing to see if permission info is cleared from > the cache. Or is the user still authenticated even when the session has > already expired? I tested with > SecurityUtils.getSubject().isAuthenticated(); > and I get true even after the session is supposed to be expired. > > Anyway, back to the topic. > > Is there any drawback to keeping session around? Let's say in the case > where > a client is impersonating users, there can potentially be 10k+ users (maybe > 1m+ if you talk about Facebook-liked service). This means that there will > be > quite a bit of open sessions. > You should be able to use the EnterpriseCacheSessionDAO for 10k users. If its backed by ehcache, you should be fine, I am not sure what it scales too. > > My original plan was to logout in the following cases: > - Client disconnect -> should log user from a particular host out only. > Other client using the same user stays logged in until disconnect. > - Logout after completion of impersonation. Basically, log user out when > user log out from the client side. I actually still need to figure out how > to intersect client app and user permissions to figure out final set of > permissions. For example, client application may have access to view any > user, but the user logging in to the client may only have access to view > own > profile only. > > Do you see any issue with this approach? Security is definitely not my > strong point so I'm still trying to figure out the best approach. The key > to > my problem is that multiple clients can potentially be using the same > username. This means that I definitely need to use hostname to > differentiate > between them. A user may already be authenticated for a client, but if > another client is trying to connect, it still has to be authenticated > again. > So even though authentication is done separately, they all should share the > same authorization info since username is the common key. > I see your point. though hostname may not work. For example I could have two sessions open from the same host. It seems the authc/authz cache should be tied to the session. Can anyone think of a downside to that? > > Also, when is Shiro 1.2 going to be available? > > Thanks, > Jack > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Authorization-Cache-Removed-when-Logged-Out-tp6360724p6361445.html > Sent from the Shiro User mailing list archive at Nabble.com. >
