I had actually thought about using the regex to fire explicit exceptions, I just hadn't thought of it till I had finished coding it the way i did. The only downside I see if we/i'd need to have the exceptions for the "all" the LDAP errors and if a deployer had an exception we didn't think of it would still require Java coding.
I'm on the jasig-cas chat now and I probably will be the rest of the day. -Andrew On Nov 16, 2011, at 10:59 AM, Scott Battaglia wrote: > I'm not super familiar with the ppolicy. We should see how that would work. > Currently we just parse the exception messages and throw new mapped > exceptions (similar to what Spring does with Oracle error codes -> data > access exceptions). > > Something to work through via chat? (and then come back to the list) > > > On Wed, Nov 16, 2011 at 10:52 AM, Marvin Addison <[email protected]> > wrote: > > 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 > > This strategy is simply inadequate for directories that communicate > account state not through error messages but via ppolicy, > http://opends.java.net/public/standards/draft-behera-ldap-password-policy.txt. > I think that exceptions are generally the right solution to > communicate detailed error conditions to higher levels of the API, but > I don't think that necessarily precludes the use of mechanisms like > you've described. I see that mechanism as one particular strategy for > selecting the proper exception to throw instead of selecting a > message. That way we can keep the authentication handler "pure" by > dealing strictly with success and failure conditions and letting some > higher-level component (e.g. webflow) maps exceptions onto messages > and performs routing as needed for good UX. With that view the > ppolicy stuff down the road just needs a different exception mapping > handler and the higher-level stuff continues to work with an invariant > set of exceptions. > > M > > -- > 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
