Realized I should have replied to this thread. I've got availability on Friday for a serious discussion if anyone's is interested/willing.
On Wed, Nov 16, 2011 at 12:58 PM, Tillinghast, Andrew P. < [email protected]> wrote: > > 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 > > -- 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
