You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by jagregory <ja...@jagregory.com> on 2011/07/11 14:33:09 UTC
Updating or invalidating Subject Principals
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?
I've seen a few places mention just storing the username (or user id,
etc...), but that would seem to make the Shiro JSP tags less useful (can't
do <shiro:principal property="firstName" />, for example).
My other question is related to the first. How should I go about
invalidating/updating the stored Principal of a Subject when changes are
made to the User entity? For example, the User entity has a GetFullName
method, which is used to display a welcome message at the top of the page
they're on. If they go into their account settings and update their name,
the previous value will still be displayed on the pages until they
reauthenticate due to the User instance being held by the Subject. Is there
a way to invalidate the Principal when the user saves changes to their
account?
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).
Any help would be much appreciated.
Thanks,
James
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Updating-or-invalidating-Subject-Principals-tp6570762p6570762.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Updating or invalidating Subject Principals
Posted by Les Hazlewood <lh...@apache.org>.
> to the bundled PrincipalTag; so all in all, there's been very little impact to this change, except it's now fixed the issues I was hitting.
Glad to hear it!
Cheers,
--
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
Re: Updating or invalidating Subject Principals
Posted by jagregory <ja...@jagregory.com>.
A very good attitude to have. Nothing worse than coming across a forum thread a year later with only a "doesn't matter, I got it working!" reply!
I was just about to report back anyway. I've changed my setup to use the userId as the Principal, instead of the User entity itself, and everything is now working as I would've expected it to! I also created a new tag to help out with accessing the User instance inline, which works in a very similar way to the bundled PrincipalTag; so all in all, there's been very little impact to this change, except it's now fixed the issues I was hitting.
Thanks again,
James.
On Monday, 11 July 2011 at 23:07, Les Hazlewood-2 [via Shiro User] wrote:
> Hi James,
>
> No worries - I've been known to be verbose in my replies ;) But I'd
> rather be verbose in the hopes that it helps anyone reading messages
> in the future than to be too short.
>
> In any event, welcome to the Apache Shiro community!
>
> Best regards,
>
> Les
>
> On Mon, Jul 11, 2011 at 12:51 PM, jagregory <[hidden email] (/user/SendEmail.jtp?type=node&node=6572943&i=0)> wrote:
>
> > Somehow this doesn't feel like an adequate response to the amount of effort
> > you've obviously put in to your replies... but thank you, that confirms my
> > suspicions. I've been doing this long enough to realise if something hurts,
> > to stop doing it :)
> >
> > My only disappointment is the reduced usefulness of the principal JSP tag,
> > but I don't think it'll be difficult to roll my own wrapping the "get UserId
> > from Principal and load User instance from the database".
> >
> > So I reckon I'll remove the User from my Principals collection and just use
> > the UserId instead.
> >
> > Thanks for the help!
> >
> > James
> >
> > --
> > View this message in context: http://shiro-user.582556.n2.nabble.com/Updating-or-invalidating-Subject-Principals-tp6570762p6572395.html
> > Sent from the Shiro User mailing list archive at Nabble.com (http://Nabble.com).
>
>
> If you reply to this email, your message will be added to the discussion below: http://shiro-user.582556.n2.nabble.com/Updating-or-invalidating-Subject-Principals-tp6570762p6572943.html
> To unsubscribe from Updating or invalidating Subject Principals, click here (http://shiro-user.582556.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=6570762&code=amFtZXNAamFncmVnb3J5LmNvbXw2NTcwNzYyfC0xNzc3ODMzOTAx).
>
>
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Updating-or-invalidating-Subject-Principals-tp6570762p6572957.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Updating or invalidating Subject Principals
Posted by Les Hazlewood <lh...@apache.org>.
Hi James,
No worries - I've been known to be verbose in my replies ;) But I'd
rather be verbose in the hopes that it helps anyone reading messages
in the future than to be too short.
In any event, welcome to the Apache Shiro community!
Best regards,
Les
On Mon, Jul 11, 2011 at 12:51 PM, jagregory <ja...@jagregory.com> wrote:
> Somehow this doesn't feel like an adequate response to the amount of effort
> you've obviously put in to your replies... but thank you, that confirms my
> suspicions. I've been doing this long enough to realise if something hurts,
> to stop doing it :)
>
> My only disappointment is the reduced usefulness of the principal JSP tag,
> but I don't think it'll be difficult to roll my own wrapping the "get UserId
> from Principal and load User instance from the database".
>
> So I reckon I'll remove the User from my Principals collection and just use
> the UserId instead.
>
> Thanks for the help!
>
> James
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Updating-or-invalidating-Subject-Principals-tp6570762p6572395.html
> Sent from the Shiro User mailing list archive at Nabble.com.
Re: Updating or invalidating Subject Principals
Posted by jagregory <ja...@jagregory.com>.
Somehow this doesn't feel like an adequate response to the amount of effort
you've obviously put in to your replies... but thank you, that confirms my
suspicions. I've been doing this long enough to realise if something hurts,
to stop doing it :)
My only disappointment is the reduced usefulness of the principal JSP tag,
but I don't think it'll be difficult to roll my own wrapping the "get UserId
from Principal and load User instance from the database".
So I reckon I'll remove the User from my Principals collection and just use
the UserId instead.
Thanks for the help!
James
--
View this message in context: http://shiro-user.582556.n2.nabble.com/Updating-or-invalidating-Subject-Principals-tp6570762p6572395.html
Sent from the Shiro User mailing list archive at Nabble.com.
Re: Updating or invalidating Subject Principals
Posted by Les Hazlewood <lh...@apache.org>.
> 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.
I should have added a #3 to this list, but did talk about it later in
my reply: Sessions. If using Sessions, this same serialization is
performed if a session is serialized because the PrincipalCollection
is stored as a session attribute. The fewer principals and the more
lightweight they are, the better this will be for application
performance (which is true of any data that might be stored in a
session).
Cheers,
--
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
Re: Updating or invalidating Subject Principals
Posted by Les Hazlewood <lh...@apache.org>.
Hi James,
On Mon, Jul 11, 2011 at 5:33 AM, jagregory <ja...@jagregory.com> 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