Hi Les, Thanks for the response. To see if I understand it correctly, I setup a simple experiment using a JMS service with 2 JMS clients. I simply ran the test in Eclipse so everything is single-threaded.
Anyway, here's the steps: 1) Start JMS service 2) Start JMS clients (2 instances of the same client, using the same username/password) 3) Send a message to login (server reacts to the message with property "operation=login" by logging the user in) 4) Send a message to execute some logic that requires permission from 2nd client -> successful 5) Send a message to execute some logic that requires permission from 1st client -> successful I'm not sure everything was executed successfully because the server is single threaded, but I never once had to bind subject to the thread myself. My login method basically executes this line using username/password from the JMS message SecurityUtils.getSubject().login(<username_password_token>); and the logic execution invokes SecurityUtils.getSubject().isPermitted(<permission_string>); before execute the logic. I'm not sure if I understood your response correctly. I thought for non-web application, I always have to bind the subject to the thread to make it work. Or did you mean I have to do it when I spawn off another thread? I took a look at the Spring example and looks like I would have to bind the subject to the thread of the subsequent calls. That's not what I'm seeing in my experiment. My guess is that I should be doing the following: 1) Login for every request. I can't see how the service knows which client is authenticated. It only knows which user is authenticated. It seems that I also need to clear the thread since subsequent calls is automatically bound to the same subject otherwise. 2) If I spawn off a thread, I need to bind a subject to that thread using sessionId. Sorry, I usually get it better with an example. Thanks, Jack -- View this message in context: http://shiro-user.582556.n2.nabble.com/Checking-Session-Timeout-tp6373753p6376431.html Sent from the Shiro User mailing list archive at Nabble.com.
