Hi Justin, The system property approach wasn't very clean and it has been modified significantly in subversion to look first at the Subject bound to the thread and only look at the system property as a last resort. You might want to look at/use the code in the repository until the next version of the project is released:
https://svn.apache.org/repos/asf/incubator/jsecurity/trunk/support/spring/src/main/java/org/apache/ki/spring/remoting/ And look at the SecureRemoteInvocationFactory source. You'll probably have to copy-n-paste that into your own implementation and inject that implementation at runtime until the next release. Also, you're correct - you need to use the 'ki' session mode instead of the default servlet container HTTP sessions in order to do federated session management. This is a feature that servlet containers don't have, so you'll need to use Ki's managed enterprise sessions. Let me ask a question out of curiosity though - is it your intention to have both the client grails and the server grails share the same session? Or is this more related to login/authorization only? Cheers, Les On Thu, May 28, 2009 at 1:53 AM, jtriley <[email protected]> wrote: > > Hi Les, > > I'm in the process of creating the demo apps and have a few questions. > > So far my setup consists of two grails apps: > > server grails - I have jsecurity configured with a local administrator > account. Configured two remote services, AuthService and RemoteService. I > added remoteInvocationExecutor property/ref to httpinvoker proxy bean in > the > grails remoting plugin script. > > client grails - I have jsecurity configured with a local administrator > account. I have remote proxy services configured for both Auth and Remote > services. I've setup a test controller that calls a simple method on the > remote AuthService. I added remoteInvocationExecutor property/ref to > httpinvoker executor bean in the grails remoting plugin script. The > remoteInvocationExecutor bean has a securityManager property/ref to the > jsecSecurityManager bean used by the jsecurity plugin. > > Without implementing a RemoteRealm I just tried things as is. The remote > service call failed telling me I needed to specify a jsecurity.session.id > system property. Looking at the spring example I determined that this was > simply the session id from logging into the server in a browser. > > So I wrote a controller on the server grails to print the session id after > successful login and then used this value to start the client grails. After > specifying jsecurity.session.id with the session id obtained from logging > into the server I get the following message in a stack trace. > > org.codehaus.groovy.runtime.InvokerInvocationException: > org.jsecurity.session.InvalidSessionException: Specified id [zt2xj4ihdhbj] > does not correspond to a valid Session It either does not exist or the > corresponding session has been stopped or expired. > at > > org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382) > at > > org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180) > Caused by: org.jsecurity.session.InvalidSessionException: Specified id > [zt2xj4ihdhbj] does not correspond to a valid Session It either does not > exist or the corresponding session has been stopped or expired. > at > > org.jsecurity.mgt.SessionsSecurityManager.getSession(SessionsSecurityManager.java:187) > at > > org.jsecurity.spring.remoting.SecureRemoteInvocationExecutor.invoke(SecureRemoteInvocationExecutor.java:112) > at > > org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382) > at > > org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180) > at $Proxy3.getSecuritySubject(Unknown Source) > at TestController$_closure1.doCall(TestController.groovy:7) > at TestController$_closure1.doCall(TestController.groovy) > ... 2 more > > This stacktrace was produced from the client as a consequence of invoking > the remote method getSecuritySubject in the remote AuthService. For now > that > is a simple dummy method that returns a String just to test RMI from end to > end. I believe everything after $Proxy3.getSecuritySubject(Unknown Source) > happens on the remote end. > > I had a suspicion that maybe this had to do with this > jsecurity.session.mode > property being http by default. As a shot in the dark I tried changing both > client/grails jsecurity.session.mode to 'jsecurity' but this failed because > of a missing class def: > > org.codehaus.groovy.runtime.InvokerInvocationException: > java.lang.NoClassDefFoundError: > edu/emory/mathcs/backport/java/util/concurrent/Executors > at > > org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:382) > at > > org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:180) > Caused by: java.lang.NoClassDefFoundError: > edu/emory/mathcs/backport/java/util/concurrent/Executors > at > > org.jsecurity.session.mgt.ExecutorServiceSessionValidationScheduler.enableSessionValidation(ExecutorServiceSessionValidationScheduler.java:75) > at > > org.jsecurity.session.mgt.AbstractValidatingSessionManager.enableSessionValidation(AbstractValidatingSessionManager.java:219) > at > > org.jsecurity.session.mgt.AbstractValidatingSessionManager.enableSessionValidationIfNecessary(AbstractValidatingSessionManager.java:92) > at > > org.jsecurity.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:158) > at > > org.jsecurity.session.mgt.AbstractSessionManager.start(AbstractSessionManager.java:62) > at > > org.jsecurity.web.session.DefaultWebSessionManager.start(DefaultWebSessionManager.java:223) > at > > org.jsecurity.web.session.DefaultWebSessionManager.start(DefaultWebSessionManager.java:219) > at > > org.jsecurity.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:178) > at > > org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:284) > at > > org.jsecurity.subject.DelegatingSubject.getSession(DelegatingSubject.java:272) > at AuthController$_closure6.doCall(AuthController.groovy:71) > at AuthController$_closure6.doCall(AuthController.groovy) > ... 2 more > > I'm hoping to get this method working first (ie passing the session id at > startup) since this is the lowest hanging fruit. Ideally a Realm > implementation, as we've discussed, would help me to obtain the session id > at runtime without needing to obtain it before hand, however I imagine > that'll be easier once I know this jsecurity.session.id method works as a > baseline. Any thoughts/suggestions appreciated as always. > > And I'll be sure to add issues/suggestions to Jira as I encounter them. > > Thanks Les, > > ~jtriley > > > Les Hazlewood-2 wrote: > > > > No prob - glad to help. I'll look forward to the demo :) > > > > Also, if you see anything along the way that would make (or would have > > made) > > your life easier, please add these suggestions as Jira issues. Federated > > SecurityManager support should be a first class citizen in a later > > release, > > so anything you come across along the way could help others in the > future. > > > > -- > View this message in context: > http://n2.nabble.com/integrating-jsecurity-ki-auth-with-spring%27s-httpinvoker-tp2898395p2985681.html > Sent from the JSecurity User mailing list archive at Nabble.com. > >
