Re: wicket-ki-security

[Tauren Mills <yo...@gmail.com>]

Les,

Thanks for posting this to the user list and your suggestions. The
wicket-shiro project already had UserService implemented the way you
suggested, but I just wasn't using it effectively in UserAuthHeader.  I've
updated the UserAuthHeader to call getCurrentUser().  I have not added a
ShiroService to the wicket-shiro sample, but I can see how it would prove
useful in a real project. Perhaps I'll add it to the sample later.

So I'm curious about the status of getting Shiro into a maven repository.
Any estimates on when that might happen?

Thanks!
Tauren


On Sat, Jun 27, 2009 at 12:38 PM, Les Hazlewood <lh...@apache.org>wrote:

> Hi Tauren,
>
> I'm forwarding this to the Shiro user list as the answer could benefit
> other people as well.
>
> The User object itself should probably never be stored in the Subject or
> its Session - just the ID as you've pointed out.  This is definitely the
> appropriate way to use Shiro for most enterprise applications.
>
> The reason is that, especially with JPA/Hibernate applications, If Shiro
> stored the User object directly, it would bypass lots of optimizations that
> are in place in persistence frameworks, such as caching.
>
> That is, you should almost always lookup the User object during a
> transaction via the Subject-accessible user ID, and rely on a nice caching
> framework to improve performance if you don't want an expensive 'round trip'
> to the database each time you do the lookup.
>
> This is especially important for coherency - if you cache a User object in
> the Subject (or the Subject's Session), and you change that User object
> somewhere else in the application (say, via an 'update account' web page),
> well, now the User object in your session is 'stale' and does not reflect
> the one changed by visiting the 'update account' web page.
>
> This beneficial technique is not unique to just Shiro of course - most
> session values should usually be extremely lightweight objects - ids or
> lookup keys to pull the corresponding 'real' object via a Service or DAO
> call, relying on the underlying persistence framework and caching to help
> with performance, data versioning, coherency, etc.
>
> So a good practice is to have a 'utility' helper component that can do this
> translation automatically.
>
> For example, UserService#getCurrentUser():
>
> public User getCurrentUser() {
>     Long id = (Long)SecurityUtils.getSubject().getPrincipal();
>     if ( id != null ) {
>         // they are either authenticated or remembered from a previous
> session,
>         // so return the user:
>         return getUser(id);
>     } else {
>         //not logged in or remembered:
>         return null;
>     }
> }
>
> I've taken this concept a little further and I wrap all my
> SecurityUtils.getSubject().* method operations by creating a SubjectService
> interface:
>
> public interface SubjectService {
>
>     User getCurrentUser();
>
>     hasRole(String role);
>
>     isPermitted(String permission);
>
>     //more Subject 'wrapper' methods as necessary
>
>     setSessionAttribute(Object key, Object value);
>     removeSessionAttribute(key);
>
>     //etc..
> }
>
> Then you would write a ShiroSubjectService implementation of this
> interface that calls the Shiro SecurityUtils/Subject API.
>
> The benefit here is that all of your code deals with the SubjectService for
> everything, and never needs to 'know about', i.e. import any of Shiro's
> APIs - very loosely coupled.  Granted, you wouldn't need to use such an
> abstraction for wicket-shiro integration, but this approach is very useful
> in enterprise applications where you want to decouple you and your
> programming team from any 3rd party APIs as best as possible.
>
> I hope that helps!
>
> Cheers,
>
> Les
>
>
> On Sat, Jun 27, 2009 at 12:52 PM, Tauren Mills wrote:
>
>> Les,
>>
>> Just wanted to let you know I renamed the project to wicket-shiro.  I also
>> added a spring/hibernate example to it.  But I was wondering if I should be
>> getting the username out of the subject in a better way than this:
>>
>> @SpringBean(name = "userService")
>> private UserService userService;
>>
>> public UserAuthHeader(String id, Class<? extends Page> loginPage)
>> {
>>   super( id );
>>
>>   add( new Label( "name", new AbstractReadOnlyModel<String>() {
>>     @Override
>>     public String getObject() {
>>       Long id = (Long) SecurityUtils.getSubject().getPrincipal();
>>       return userService.getUser(id).getUsername();
>>     }
>>   }) );
>> }
>>
>> With the user being a Hibernate User entity, the principle is a Long id.
>> So I'm using that to find the User from the userService and return the
>> username. But is the User object stored in the Subject somewhere? I didn't
>> locate it when I was tracing the code.
>>
>> See here for the full java file:
>>
>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/shiro-security/wicket-shiro-examples/shiro-example-spring-hibernate/src/main/java/org/wicketstuff/shiro/example/sprhib/UserAuthHeader.java
>>
>> Thanks!
>> Tauren
>
>
>