Thank you Les, I have, very carefully, looked read the Subject API document per you suggestion. I don't disagree with your argument at all. I think we are just thinking in different ways. I am not trying to do something akin to token login - trading credentials for a token and using the token in the form of a cookie to perform logins. All I am trying to do is store the Shiro session data in a server-side secret encrypted cookie. This would be a session cookie no different in scope or replayability then the JSESSION cookie. Now, I agree that there is some performance penalty to encrypt, decrypt this data and there are two ways of mitigating it: 1. As you suggest use a clustered cache. 2. Keep a local session (current scenario) and replace with the crypto session cookie if it is newer.
I prefer 2 for our implementation since it keeps configuration simpler - which in our case is important. I think another issue here is that I have inadvertently hijacked this thread. I started out about signaling state to the client, and evolved (or devolved depending on your opinion) into the conversation about session state management. Still, now that, hopefully, explained my thinking, I would appreciate advice on where would be the best place to plug in. Thank you, Mike. -- View this message in context: http://shiro-user.582556.n2.nabble.com/Permission-checking-on-client-side-tp5450587p5457627.html Sent from the Shiro User mailing list archive at Nabble.com.
