Hi Jim, Please see inline: > I'm looking at using shiro in a (swing-based) client/server application, > using a "remoting" approach (like rmi, spring remoting, but this is a custom > implementation as I won't be using shiro's spring support) -- so the client > gets a remote proxy of some service interfaces that the server exports. > > What I'm currently thinking is that authentication will be an explicit > operation that the client can perform, which will result in it acquiring a > session token that can be sent with each subsequent invocation request. The > server will use the session token provided by the client to add the > appropriate subject to the invocation context before the invocation is made. > It looks like I can use shiro's session id as the session token.
Yep, this is fairly common. We have a Java Web Start sample application that you can use for ideas. It uses Spring remoting, but the concepts are the same regardless of the remoting mechanism - you just need to ensure that the session ID accompanies the remoting payload somehow. > 1. Can I create a session without logging in? This might be useful if we > implement some unprivileged client behavior which doesn't require login. Yep, absolutely. A subject.getSession() call will return a new session if one does not yet exist, regardless of authentication/rememberMe state. > 2. If the user logs in and then subsequently logs out (or is timed out), is > the session gone? Is the session id no longer valid? This would mean that > I would have to send a new session id to the client. In the case of a log out or expiration timeout, any further interactions under the old session ID would cause an InvalidSessionException. It is the responsibility of the client (or the server acting on behalf of the client) to catch these exceptions and act accordingly (e.g. transparently create a new session, or show the user some view to force a new login, etc). For example, Shiro's web support does this automatically (since the web layer is considered a client tier). If the client browser sends an old session ID cookie, Shiro's web module will catch the exception and transparently remove the old session id cookie. If the request then needs a new session, the new session's id is automatically added to the response as a new cookie. As to whether or not if the session is 'gone': when a session is stopped explicitly, or stopped automatically via logout, or expired due to inactivity, in all cases that particular session is no longer usable. However, the raw session data may still exist in the session backing data store (abstracted in Shiro via a SessionDAO). The Shiro SessionManager implementation's default behavior is to permanently delete all sessions upon discovering they are stopped or expired. However, this behavior can be turned off where it is expected that some process external to Shiro will clean up the session store (e.g. a Quartz job or cron job) to prevent long-term orphans. This feature exists because some people want to run queries on the data store to gather statistics about user's session usage (how long an average session lasts, how many sessions per user, etc). (My personal feeling is that this doesn't scale well and that queries should be run on logged data sets, such as via Hadoop). This may be a little more than what you were asking for, but just know that in all cases, once a session has expired or is stopped, it can no longer be accessed by the application - at least not through Shiro. Finally, for rich client applications, the session.touch() method might be of interest. It should be used appropriately to ensure that sessions aren't left open forever, but it could be useful in some situations. That method's JavaDoc should help clarify things. > 3. I understand that I can use the following to look up a subject for a > given session: > > subject = new > Subject.Builder(securityManager).sessionId(sessionId).buildSubject(); > > But what happens if the sessionId is not valid? Will I get a new > (unauthenticated) subject without a session? Will it implicitly create a > session? Will subject construction fail? In my case, if the session is no > longer valid I would need to construct a new session and then relay the new > session id to the caller. The buildSubject() call in this case would fail with an InvalidSessionException - the assumption is that because you're providing a specific ID, you must know more than Shiro does that you expect a session to be there. However, it is quite easy to catch that exception and automatically build a new Subject if that occurs. It is just hard for Shiro to do this automatically because it is very specific to the client being built, which is impossible for us to know about a priori. But if anyone out there has suggestions to make this better, we're all ears! Anyway, I hope that helps! Best, Les
