The exceptions should be as explicit as they need to be to get the job done. Java can't easily make decisions when it needs to extract details from the message itself. If an account is locked, there is no reason not to throw an account locked exception.
CAS4 API uses the Java6 exception hierarchy as its starting point, e.g. http://download.oracle.com/javase/6/docs/api/javax/security/auth/login/AccountLockedException.html The CAS4 API for password policy uses explicit exceptions also and there are no plans to change that. I also don't see what the point would be in the LPPE if we didn't map to useful exceptions (how much better is it than parsing LDAP error codes at that point?) On Tue, Nov 15, 2011 at 3:45 PM, Tillinghast, Andrew P. < atill...@conncoll.edu> wrote: > > > Last week during the unconference I had the opportunity to review my > proposed LPPE changes with Bill Thompson and Andrew Petro, during the topic > of CAS error handling came up and it seemed like it was a topic that needed > broader discussion then the three of us could cover. > > In the previous iteration of the LDAP Password Policy Enforcement the LDAP > errors were mapped into explicit exception each with a separate custom > error handler and in the new version LPPE is throwing a generic > BadCredentialsAuthenticationException where a regex pattern and error > message is defined in the Spring Configuration. While there isn't a clear > reason to choose one method over the other I felt the generic exception and > spring configuration made customization of LPPE for different LDAP servers > accessible to more deployers. The explicit exceptions required the deployer > to know basic java rather then just XML. > > It would seem the original direction of CAS was towards explicit > exceptions, there is even a BlockedCredentialsAuthenticationException in > the CAS core but in a casual search of the code I couldn't find any place > where the exception was thrown or handled. > > Bill, Andrew and I came up with a compromise of sorts and I did like to > see if the CAS developer community at large was comfortable with it. > > Generic Exceptions for "expected" exceptions, for example in the normal > workflow we expect some user's will get an account disabled message from > LDAP, it makes sense to throw this as a generic exception and allow some > form of error handling. > > Explicit Exceptions for "exceptional" exceptions (Andrew Pero's term, not > mine), for example a view not found while processing login flow - These > exceptions should be explicit so they can be easier to track in logging and > in researching the cause. > > > I don't know if i was very eloquent in explaining the discussion but it > seems that the community's take on this is key to determining if my > proposed changes to LPPE are acceptable or not. > > Andrew Tillinghast > Sr. Web Developer > atill...@conncoll.edu > ****270 Mohegan Avenue******** > ****New London**, **CT** **06320-4196******** > Ph:860 439-5265 Fax: 860 439-2871**** > P *Think before you print > ***CONFIDENTIALITY: This email (including any attachments) may contain > confidential, proprietary and privileged information, and unauthorized > disclosure or use is prohibited. If you received this email in error, > please notify the sender and delete this email from your system. > > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
