The expectation or goal is that we ship with as many useful translators as possible and the simple API allows for people to contribute more configurable translation.
On Wed, Nov 16, 2011 at 9:35 AM, Tillinghast, Andrew P. < [email protected]> wrote: > > The issue I'm attempting to address is that each flavor of LDAP returns a > different error message for account conditions such as locked. > > The original LPPE had explicit exception such as LDAPAccountLocked that > used a regex pattern to determine if the error thrown by the LDAP mapped to > the explicit exception, each exception also had a separate error handler > that then mapped the error to a flow action. > > The problem I saw with this method was that in order for a deployer to use > an LDAP server other the Active Directory they need sufficient JAVA > knowledge to write their own exceptions and to add them into the LDAP > exception chain. > > > What I wrote into the proposed LPPE module is a class that accepts Regex / > Error message pairs that are configured via spring, the deployer is able to > specify a regex pattern and what error message to throw in response, the > errors are thrown as a BadCredentialsAuthenticationException exception. > There is also a error handler web flow class that reads the message context > and again based on spring configuration maps an error message to a flow > action. > > > -Andrew > > On Nov 15, 2011, at 4:33 PM, Scott Battaglia wrote: > > 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. < > [email protected]> 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 >> [email protected] >> ****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 [email protected] as: >> [email protected] >> >> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > -- > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
