Hi James, On Mon, Jul 11, 2011 at 5:33 AM, jagregory <[email protected]> wrote: > Hello everyone, > > I'm just getting started with Shiro really, so I'm fully open to the idea > that I'm doing it all wrong. > > My technology stack shouldn't really factor into this question, all you > really need to know is it's a web app using Hibernate. > > First question. I have a Hibernate POJO entity called User, which is fetched > by my custom HibernateRealm and stored as a Principal against the Subject. > Is this recommended practice?
Shiro defines a principal as "an identifying attribute of a Subject". For example, username, user ID, etc. These are all attributes or "properties' if you like. A principal is expected to be a pointer to data and not expected to be an actual complex object itself. The reason for this is twofold: 1. Shiro will (optionally encrypt) and serialize a Subject's PrincipalCollection (and therefore all of the principals it contains) and store this byte array as the "rememberMe" cookie for remember me services (if you use RememberMe). The bigger the principal collection, the bigger performance impact it would have on your app in serializing/deserializing. 2. As you've alluded to, Shiro has no mechanism of invalidating and updating a complex object in the principal collection if you change another representation of it elsewhere. For applications that usually store, say, a user ID only in the PrincipalCollection, then yes, the <shiro:principal/> tag is not useful - most apps never want to show some number or UUID to the user as it isn't very readable/user-friendly. These apps usually use another approach for rendering page output: It is a common approach to use the Subject's primary principal during a request, look up the corresponding User object, and place that user object in the Page context (or whatever MVC mechanism you use) - then you can use the User object directly in the page. For example, if using Velocity to render views, you could do something like this: Hello $user.givenName, how are you today? The other approach *is* to use a complex object as a principal (where <shiro:principal/> will work just fine) as long as it isn't too big and not complex (e.g. a Hibernated object would not be a good idea - if it is serialized, odds are high that lazy-loading would kick in and you'd have a _massive_ object graph). For example, create a UserPrincipal class that stores the user id, the username, and maybe their first and last name and that's it. This object wouldn't require much data when serialized. Also note that even if you don't use RememberMe, but you do use sessions (the Servlet Container's or Shiro's), then by default the PrincipalCollection is stored as a session attribute so Shiro can know who 'owns' that session. Most sessions are serializable to enable disk-overflow, so the bigger your session is the more memory/diskspace/IO you will require. So, the basic idea is that "pointer" principals are best, very small, simple objects are second-best, and large/complex objects are not a good idea in pretty much all cases. > I've read something about an Authentication Cache, which sounds promising, > but haven't been able to find any documentation (only real mention of it is > here: > http://shiro-user.582556.n2.nabble.com/Invalidating-Authentication-Cache-slows-performance-td6329816.html). Yes, the Authentication Cache is a new feature for Shiro 1.2 and hasn't been released yet (which is why there isn't any documentation for it yet). However, if you're using Hibernate and 2nd-level caching where your User objects are already cached, there is no need to enable a Shiro-specific AuthenticationCache (since the data you're interacting with for Authentication - the User - is already cached). We just so happened to talk about this recently with respect to Authorization Caches as well: http://shiro-user.582556.n2.nabble.com/Subject-custom-data-from-database-tp6559272p6563678.html HTH! Best, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com
