Yep, the session ID needs to be sent to the origin server with each remote method invocation. You probably don't see this because our examples currently use Spring remoting over HTTP, which has cookie support. The session id is sent on each http remoting request in a cookie.
You don't need a SecurityManager in the client VM - just the server. But the client remoting mechanism must attach the session id to the remoting payload so the server can know how to associate the call with the appropriate Subject during the server-side invocation. HTH, Les On Tue, Jan 5, 2010 at 1:31 PM, rchristy <[email protected]> wrote: > > Sorry for the previous null post. I did have one question. My client does > run in a separate VM as the server and the only way I was able to get this > to work was to pass the session id back to the client from the server (using > ehcache to cache the subject on the server) and than rebuild the subject on > the server on all subsequent calls using code I found on an earlier post. > Seems to be that the SecureRemotingInvocationFactory/Executor should have > done that for me but with the client running in a separate vm from the > server I kept getting exceptions on the client about my application not > being configured properly and missing a security manager. My question is if > you are running in two separate vms are you required to create a security > manager in each vm and "share" a session cache that can be accessed by both > vms to get this working. I am still a bit confused because all the examples > I have seen dont need to pass the session id around. It seems that > something was doing this beind the scenes and the only thing I can think of > is the SecureRemoting hooks. > -- > View this message in context: > http://n2.nabble.com/Evaluation-Question-tp4251098p4256601.html > Sent from the Shiro User mailing list archive at Nabble.com. >
