Hi Les, I think that exposing those two methods works just fine. I think it makes sense since they are already there and it obviously wouldn't be invasive or anything to expose them now. Last night I actually made the getSubjectBySessionId a public method for my project, and it worked just as I needed it to. No objections on this side :-).
Craig Les Hazlewood-2 wrote: > > I thought about this a bit today, and I think the following on the > SecurityManager interface (and then also SecurityUtils) would be suitable: > > SecurityManager#getSubjectBySessionId( Serializable sessionId ); > SecurityManager#getSubject(PrincipalCollection principals); > > Both methods would help framework developers - the first is useful in > remoting/SSO scenarios, the 2nd useful in daemon process calls when you > may > not need to authenticate or have a session. The 2nd call is essentially > what happens in a 'remember me' scenario when someone first visits a > website > without a session - the identity is assumed, but there is no initial > session > and it is not authenticated. > > Any objections from anyone? > > The interesting thing about these two methods is that they already exist > as > private/protected methods on the underlying DefaultSecurityManager > implemetation - maybe the should exposed now that we have some decent use > cases? > > - Les > > -- View this message in context: http://n2.nabble.com/Subject-access-outside-of-a-web-environment-tp1694632p2929020.html Sent from the JSecurity Developer mailing list archive at Nabble.com.
