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 <[email protected]> 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
