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
