You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2011/02/23 22:48:20 UTC

DAO exception hierarchy

Currently we have no way of representing data access exceptions - i.e.
why interacting with a data resource failed.  The existing Realm
implementations throw AuthenticationException or
AuthorizationException when encountering these types of errors, which
is mostly incorrect - these types of exceptions don't indicate a
problem with the user's submission , but rather with the resources
used to perform authentication or authorization.

I'd like to create a new org.apache.shiro.dao package and create a
root DataAccessException (similar to Spring's) and create a few
cursory subclasses, like CommunicationException, etc.

My desire for this came about when working with the JndiLdapRealm
implementation: I need to be able to distinguish whether or not
authentication fails due to invalid user data (wrong password, etc) or
if it is due to an invalid LDAP configuration.  The former can be
represented to the user while the latter should be presented to the
developer configuring Shiro - quite different use cases.

In solving this for the LDAP realm, it would enable the same exception
hierarchy to be used in other realms trying to indicate similar
problems, providing a cohesive solution.

Any objections? Thoughts?

Thanks,

Les

Re: DAO exception hierarchy

Posted by Les Hazlewood <lh...@apache.org>.
Great feedback - thanks for chiming in Jared.

The original idea (way back when) for wrapping other exceptions was
that in the event of a non AuthenticationException, it is often
considered ugly to let that propagate all the way up to the
application end user.  But I agree that there are better ways of
solving this on the UI side and shouldn't be 'hidden' by wrapping.

Thanks,

Les

On Wed, Feb 23, 2011 at 2:00 PM, Jared Bunting
<ja...@digitalreasoning.com> wrote:
> I like the idea.  I would also point out that AllSuccessfulStrategy
> wraps any thrown Exception in an AuthenticationException.  This makes it
> very difficult to subclass ShiroException directly for something that
> (in an HTTP context) should return a 500 to the user.  So, I would
> suggest that this change include not mapping things to
> Authentiation/AuthorizationException that aren't.
>
> On 02/23/2011 03:48 PM, Les Hazlewood wrote:
>> Currently we have no way of representing data access exceptions - i.e.
>> why interacting with a data resource failed.  The existing Realm
>> implementations throw AuthenticationException or
>> AuthorizationException when encountering these types of errors, which
>> is mostly incorrect - these types of exceptions don't indicate a
>> problem with the user's submission , but rather with the resources
>> used to perform authentication or authorization.
>>
>> I'd like to create a new org.apache.shiro.dao package and create a
>> root DataAccessException (similar to Spring's) and create a few
>> cursory subclasses, like CommunicationException, etc.
>>
>> My desire for this came about when working with the JndiLdapRealm
>> implementation: I need to be able to distinguish whether or not
>> authentication fails due to invalid user data (wrong password, etc) or
>> if it is due to an invalid LDAP configuration.  The former can be
>> represented to the user while the latter should be presented to the
>> developer configuring Shiro - quite different use cases.
>>
>> In solving this for the LDAP realm, it would enable the same exception
>> hierarchy to be used in other realms trying to indicate similar
>> problems, providing a cohesive solution.
>>
>> Any objections? Thoughts?
>>
>> Thanks,
>>
>> Les

Re: DAO exception hierarchy

Posted by Jared Bunting <ja...@digitalreasoning.com>.
I like the idea.  I would also point out that AllSuccessfulStrategy
wraps any thrown Exception in an AuthenticationException.  This makes it
very difficult to subclass ShiroException directly for something that
(in an HTTP context) should return a 500 to the user.  So, I would
suggest that this change include not mapping things to
Authentiation/AuthorizationException that aren't.

On 02/23/2011 03:48 PM, Les Hazlewood wrote:
> Currently we have no way of representing data access exceptions - i.e.
> why interacting with a data resource failed.  The existing Realm
> implementations throw AuthenticationException or
> AuthorizationException when encountering these types of errors, which
> is mostly incorrect - these types of exceptions don't indicate a
> problem with the user's submission , but rather with the resources
> used to perform authentication or authorization.
> 
> I'd like to create a new org.apache.shiro.dao package and create a
> root DataAccessException (similar to Spring's) and create a few
> cursory subclasses, like CommunicationException, etc.
> 
> My desire for this came about when working with the JndiLdapRealm
> implementation: I need to be able to distinguish whether or not
> authentication fails due to invalid user data (wrong password, etc) or
> if it is due to an invalid LDAP configuration.  The former can be
> represented to the user while the latter should be presented to the
> developer configuring Shiro - quite different use cases.
> 
> In solving this for the LDAP realm, it would enable the same exception
> hierarchy to be used in other realms trying to indicate similar
> problems, providing a cohesive solution.
> 
> Any objections? Thoughts?
> 
> Thanks,
> 
> Les