On Tue, Jun 16, 2009 at 1:38 PM, Les Hazlewood<[email protected]> wrote: > I just wanted to be very clear to most readers and users of the framework > that auto-login - where the end-user is automatically logged in without > their required interaction, is usually a really, really bad idea. It is not > something that should be done by default (and is why we don't do it by > default).
Certainly, especially if you are given exactly the same permissions. > My point was this doesn't matter much if the programmer uses Shiro's API > properly. If the API is being used correctly, it would protect certain site > areas depending on their state (anonymous, remembered, and/or .. snip .. > <shiro:guest/> > <shiro:user/> > <shiro:authenticated/> > There are tags that represent the inverse of these as well. I hope JSP tags are a thing of past by now :) > But if you disagree that this doesn't provide the same end-goal as what the > article advocates, albeit in a different way, I'd certainly like to hear > your thoughts on why - if there is something that can be added to the > framework to make lives easier for people, it probably should be > incorporated :) Still not seeing the difference? Ok, let's take a real world example. Bank of America's website remembers your username on that computer (ip) only. If you move to a different location (say you suddenly changed countries), it'll ask you a simple security question *before* it gives you a chance to type in your password - so the "remember me" works as an extra security feature rather than weaker form of security. Obviously simply accepting the given client-side identity is not enough. If you type in the wrong password, the implementation can invalidate your remembered identity on the server. If somebody intercepts your identity cookie it won't be valid anymore on the next try. You can also better protect against systematic attacks since the assigned key is unique (rather than the same encrypted identity) so all keys can be invalidated at once. >> Ok, so it's clear that Shiro's rememberme is only to used for >> remembering the identity. > > That's the default yes - but not limited to that. The developer can do > whatever he likes by implementing the RememberMeManager interface. You're ... snip ... > Same with Shiro - we just provide a nice default that works assuming you use > the API correctly. The developer can certainly override this if they desire > by providing their own RememberMeManager implementation. Are you suggesting I'd do something like SecurityUtils.getSubject().login() as part of RememberMeManager.getRememberedPrincipals()? That doesn't sound like the right approach to me. I mean I don't see how RememberMeManager interface can be used directly since it doesn't support onLogin(PrincipalCollection subjectPrincipals) (because rememberme is strictly limited to identity). Obviously I can hack Shiro anyway I like (and believe me, I have) but don't you think that the design dictates that in this case it'd be better just to implement a custom SecurityManager that incorporates some aspects of RememberMeManager? If not, how would you implement this using the RememberMeManager? Kalle
