You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by NabbleSometimesSucks <bi...@yahoo.com> on 2013/03/18 17:29:24 UTC

Getting a ClassCast Exception with taglib SimpleSession

Not sure what to do here. There isn't anything in the stack trace that I see
pointing to our custom code, so it might be something internal?



Thanks

Mark



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Getting-a-ClassCast-Exception-with-taglib-SimpleSession-tp7578430.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Getting a ClassCast Exception with taglib SimpleSession

Posted by NabbleSometimesSucks <bi...@yahoo.com>.
Thanks. Yes, I see that when you cache you are caching the entire Subject.

All our cache needs to reside in Redis. But thanks for the suggestion, but
we would rather have a solution using Redis. As that is what our Socket
servers will have access to is Redis. It cannot have access to an in-memory
cache like eh-cache, because of ClassLoaders.

THanks

Mark



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Getting-a-ClassCast-Exception-with-taglib-SimpleSession-tp7578430p7578530.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Getting a ClassCast Exception with taglib SimpleSession

Posted by Jared Bunting <ja...@peachjean.com>.
Well, if you're calling setCacheManager on the realm, you're caching
authorization.  And my suggestion was to continue using redis for sessions,
and use something simple and local for authorization.


And, no we aren't caching authentication stuff, just Session. Also we only
have one cache, so CacheManager only returns that one cache.

Thanks

Mark



--
View this message in context:
http://shiro-user.582556.n2.nabble.com/Getting-a-ClassCast-Exception-with-taglib-SimpleSession-tp7578430p7578497.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Getting a ClassCast Exception with taglib SimpleSession

Posted by NabbleSometimesSucks <bi...@yahoo.com>.
And, no we aren't caching authentication stuff, just Session. Also we only
have one cache, so CacheManager only returns that one cache.

Thanks

Mark



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Getting-a-ClassCast-Exception-with-taglib-SimpleSession-tp7578430p7578497.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Getting a ClassCast Exception with taglib SimpleSession

Posted by NabbleSometimesSucks <bi...@yahoo.com>.
We can't use ehcache or others because of the Socket connection apps. We are
using Redis as our Session Management and for Socket session management for
security reasons, and we need the backend persistence, which an in-memory
cache/cluster won't give us. Think of us as a bank. That data can't be lost
for any reason.

Thanks

Mark




--
View this message in context: http://shiro-user.582556.n2.nabble.com/Getting-a-ClassCast-Exception-with-taglib-SimpleSession-tp7578430p7578496.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Getting a ClassCast Exception with taglib SimpleSession

Posted by Jared Bunting <ja...@peachjean.com>.
Technically, setting the cacheManager should be fine provided that the
cache manager returns a different cache for each name passed to "getCache".
 In reality, you probably don't want to use a redis-based cache for
authorization - in the authorization case, the goal of the cache is to
reduce the amount of hits to your postgres DB.  So it would make more sense
to use something in-process like ehcache here (i think).


On Thu, Mar 21, 2013 at 11:04 AM, NabbleSometimesSucks <
bigtrashcaninthesky@yahoo.com> wrote:

> Yes we are using custom caching.
>
> Our Realm uses data from a Postgres database
>
> Our custom Cache is using data from Redis.
>
> At first when looking at the code we use in the Realm, there is no code
> directly referencing our Cache or CacheManager, but looking at our Spring
> configuration I am setting the cacheManager property in the Realm, which
> comes from extending AuthorizingRealm.
>
> I actually, haven't seen this exception come up anymore, but are you saying
> I shouldn't be setting the cacheManager property?
>
> Here is our code
>
> @Transactional
> public class BlahRealm extends AuthorizingRealm {
>
>   @Autowired
>   ApplicationContext context;
>
>   private AccountService accountService;
>
>   private AccountService getAccountService() {
>     if (this.accountService == null) {
>       this.accountService = context.getBean(AccountService.class);
>     }
>     return this.accountService;
>   }
>
>   private SimpleAccount getAccount(String username) {
>     AccountSecurity accountSecurity =
> getAccountService().findByUserName(username);
>     if (accountSecurity == null) {
>       return null;
>     }
>
>     //ByteSource byteSource =
> ByteSource.Util.bytes(accountSecurity.getSaltValue());
>     MutablePrincipalCollection principalCollection = new
> SimplePrincipalCollection();
>     principalCollection.add(accountSecurity.getUsername(), getName());
>     principalCollection.add(accountSecurity.getId(), getName());
>
>     SimpleAccount account = new SimpleAccount(principalCollection,
> accountSecurity.getPassword(), getName());
>     Set<UserRole> roles = accountSecurity.getRoles();
>     for (UserRole role : roles) {
>       account.addRole(role.getRole());
>     }
>
>     Set<UserGroup> groups = accountSecurity.getGroups();
>     for (UserGroup group : groups) {
>       account.addStringPermission(group.getName());
>     }
>     return account;
>   }
>
>   @Override
>   protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
> principals) {
>     String username = (String)principals.getPrimaryPrincipal();
>     return getAccount(username);
>   }
>
>   @Override
>   protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken
> authenticationToken) throws AuthenticationException {
>     UsernamePasswordToken upToken = (UsernamePasswordToken)
> authenticationToken;
>     return getAccount(upToken.getUsername());
>   }
>
>   @Override
>   public String getName() {
>     return "BlahRealm";
>   }
>
>   @Override
>   public boolean supports(AuthenticationToken authenticationToken) {
>     return (authenticationToken instanceof UsernamePasswordToken);
>   }
> }
>
>
>
> And here is our Spring configuration for that bean
>
>     <bean id="blahRealm"
> class="com.blah.account.security.shiro.realm.BlahRealm">
>         <property name="name" value="blah"/>
>         <property name="credentialsMatcher" ref="credentialsMatcher"/>
>         <property name="cacheManager" ref="cacheManager"/>
>     </bean>
>
> Thanks for taking the time to look at this. I might just remove the
> cacheManager property setting to see what happens.
>
> Thanks
>
> Mark
>
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Getting-a-ClassCast-Exception-with-taglib-SimpleSession-tp7578430p7578492.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>

Re: Getting a ClassCast Exception with taglib SimpleSession

Posted by NabbleSometimesSucks <bi...@yahoo.com>.
Yes we are using custom caching.

Our Realm uses data from a Postgres database

Our custom Cache is using data from Redis.

At first when looking at the code we use in the Realm, there is no code
directly referencing our Cache or CacheManager, but looking at our Spring
configuration I am setting the cacheManager property in the Realm, which
comes from extending AuthorizingRealm.

I actually, haven't seen this exception come up anymore, but are you saying
I shouldn't be setting the cacheManager property?

Here is our code

@Transactional
public class BlahRealm extends AuthorizingRealm {

  @Autowired
  ApplicationContext context;

  private AccountService accountService;

  private AccountService getAccountService() {
    if (this.accountService == null) {
      this.accountService = context.getBean(AccountService.class);
    }
    return this.accountService;
  }

  private SimpleAccount getAccount(String username) {
    AccountSecurity accountSecurity =
getAccountService().findByUserName(username);
    if (accountSecurity == null) {
      return null;
    }

    //ByteSource byteSource =
ByteSource.Util.bytes(accountSecurity.getSaltValue());
    MutablePrincipalCollection principalCollection = new
SimplePrincipalCollection();
    principalCollection.add(accountSecurity.getUsername(), getName());
    principalCollection.add(accountSecurity.getId(), getName());

    SimpleAccount account = new SimpleAccount(principalCollection,
accountSecurity.getPassword(), getName());
    Set<UserRole> roles = accountSecurity.getRoles();
    for (UserRole role : roles) {
      account.addRole(role.getRole());
    }

    Set<UserGroup> groups = accountSecurity.getGroups();
    for (UserGroup group : groups) {
      account.addStringPermission(group.getName());
    }
    return account;
  }

  @Override
  protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
principals) {
    String username = (String)principals.getPrimaryPrincipal();
    return getAccount(username);
  }

  @Override
  protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken
authenticationToken) throws AuthenticationException {
    UsernamePasswordToken upToken = (UsernamePasswordToken)
authenticationToken;
    return getAccount(upToken.getUsername());
  }

  @Override
  public String getName() {
    return "BlahRealm";
  }

  @Override
  public boolean supports(AuthenticationToken authenticationToken) {
    return (authenticationToken instanceof UsernamePasswordToken);
  }
}



And here is our Spring configuration for that bean

    <bean id="blahRealm"
class="com.blah.account.security.shiro.realm.BlahRealm">
        <property name="name" value="blah"/>
        <property name="credentialsMatcher" ref="credentialsMatcher"/>
        <property name="cacheManager" ref="cacheManager"/>
    </bean>

Thanks for taking the time to look at this. I might just remove the
cacheManager property setting to see what happens.

Thanks

Mark



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Getting-a-ClassCast-Exception-with-taglib-SimpleSession-tp7578430p7578492.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Getting a ClassCast Exception with taglib SimpleSession

Posted by Jared Bunting <ja...@peachjean.com>.
Can you share your setup?  This looks like, for some reason, your realm and
your session manager are trying to use the same cache.  When the realm
tries to get AuthorizationInfo out of the cache, instead what it gets is a
session.  Are you using custom caching?

Re: Getting a ClassCast Exception with taglib SimpleSession

Posted by NabbleSometimesSucks <bi...@yahoo.com>.
We aren't. No custom Session DAO.

This was simply using <shiro:hasRole name="Player"> tag in the jsp page.
Nothing different. As noted, none of the code in the stack trace comes from
our code. I was simple trying to use the tag library to show or hide html
content based on a role.

It will work if I change it to use <shiro:authenticated> Which is fine
because anyone logged in will have the role "Player". However, at some point
later on there might be something that needs to be shown or hidden based on
a role a user has.

Mark



--
View this message in context: http://shiro-user.582556.n2.nabble.com/Getting-a-ClassCast-Exception-with-taglib-SimpleSession-tp7578430p7578433.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: Getting a ClassCast Exception with taglib SimpleSession

Posted by Les Hazlewood <lh...@apache.org>.
I'm not sure why you would reference SimpleSession from a taglib.  The
SimpleSession class is an internal implementation class used only at
the data store layer.  If you're not working with the data store layer
(e.g. writing a custom SessionDAO), all other uses are expected to be
based on the Session interface.

Regards,

Les


On Mon, Mar 18, 2013 at 9:29 AM, NabbleSometimesSucks
<bi...@yahoo.com> wrote:
> Not sure what to do here. There isn't anything in the stack trace that I see
> pointing to our custom code, so it might be something internal?
>
>
>
> Thanks
>
> Mark
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/Getting-a-ClassCast-Exception-with-taglib-SimpleSession-tp7578430.html
> Sent from the Shiro User mailing list archive at Nabble.com.