Hi Niv, You typically don't want to store complete domain objects (UserVO or otherwise) in the PrincipalCollection or return them in the AuthenticationInfo. The Subject's principals at runtime are intended to be very lightweight identifying attributes that act as 'pointers' to the complete data set. For example, an ideal principal would be a user table primary key value (e.g. a long), or a UUID, or username - essentially anything that would allow you to lookup the more complete data set at runtime.
So, you would acquire the principal (for example, if the principal was a user table rdbms primary key): Long userId = (Long)subject.getPrincipal(); //get the User object: User user = userService.getUser(userId); where 'userService' is your own application's mechanism for performing User CRUD operations and other business logic. But be sure to read the Subject#getPrincipal JavaDoc to understand how it works - especially if you have multiple realms in your application. As for storing things in the session, that's really easy: subject.getSession().setAttribute(myKey, myValue); and then retrieve it any time later: myValue = (myValueType)subject.getSession().getAttribute(myKey); Be careful with storing things in the session though - your system won't scale very well if you add a lot of data to the session: the more session data there is, the more the session management mechanism needs to store/retrieve data and the more work it has to do. The problem is greatly exacerbated when session clustering is enabled - you have much more data to send across the network connection, which can be much slower. But these session best practices are not because of Shiro's design or implementation - all session management mechanisms, such as serlvet containers like Tomcat, Jetty or JEE servers, experience the same problem. You typically want your sessions to be as lightweight as possible where they only contain 'pointer' fields that allow you to lookup the more complete information at runtime. So in the subject.getSession().setAttribute call, try to keep 'myValue' something like a long ID or String or something that can be used for lookup later. The key to performance and scalability for all of these 'pointer' scenarios is based on how your Service (and/or DAO) implementations work - typically utilizing 1st and 2nd-level caching for things like JPA or Hiberate is a good idea to ensure that the User lookups at runtime can be as fast as possible and not 'hit' your datastore every time. Each application is different - architect accordingly. HTH, Les Hazlewood Katasoft, Inc. http://www.katasoft.com On Tue, Jul 27, 2010 at 8:08 PM, nivs <[email protected]> wrote: > > Hi > > I looked around for posts on user and session. I could not find anything > particular to what I want, so do bear with me if it sounds familiar and has > been answered. > > Scenario:User Logs in: > User is authenticated and the user/subject is placed into Shiro's session in > the following way.. > > new SimpleAuthenticationInfo(userVO.getUserName(), > userVO.getPassword(),getName());(In the Realm) > > Post Login: > > 1. User does a search for things, selects an item from a list. > > What I want to achieve onSelection of the thing is: > > 1. To load the item user had selected and associate it with the subject in > session. > 2. To access the subject's principal and get access to this object/item that > was added in Step 1. > > In regard to SimpleAuthenticationInfo, will I be able to store the UserVO > object instance itself? That way I would have this 'thing' item as a member > of the UserVO? > > Thank you for the time. > Niv > > > > > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/How-to-associate-objects-with-subject-s-session-tp5345015p5345015.html > Sent from the Shiro User mailing list archive at Nabble.com.
