Ryan,

You can always attach your source to the issue if you want.

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia


On Fri, Jan 23, 2009 at 3:34 PM, Ryan Andreasen <[email protected]>wrote:

> Parker,
>
> Yes that is the JIRA issue that I created for it.  Are you trying to
> accomplish something similar to this?  I could share what I did (the source
> code files and configuration changes) if you would like.  I am not sure how
> "generic" my solution is for other institutions.  I couldn't find a great
> way to make it so; which is why I ended up having to extend the 3 core
> classes.
>
> Ryan
>
>
> On Fri, Jan 23, 2009 at 7:08 AM, Parker Grimes <[email protected]> wrote:
>
>> Ryan,
>>
>> Is this the JIRA issue you created for this?
>> http://www.ja-sig.org/issues/browse/CAS-704
>>
>> Also, would you be willing to share what you did?
>>
>> Thanks,
>> Parker
>>
>> On Thu, Sep 18, 2008 at 2:17 PM, Ryan Andreasen <[email protected]
>> > wrote:
>>
>>> Thanks for your response Scott.  I accomplished what I wanted and thought
>>> I would share.  I couldn't find a great way to handle the LDAP error codes,
>>> so I ended up extending the
>>> AbstractLdapUsernamePasswordAuthenticationHandler,
>>> AuthenticatedLdapContextSource, and FastBindLdaputhenticationHandler.  Then
>>> I created my own exceptions with error codes.  My
>>> AuthenticatedLdapContextSource checks the ldap errors and throws the correct
>>> exception.  These eventually trickle up the the AuthenticationViaFormAction
>>> where their codes are put in the error context.  Then I mapped these error
>>> codes to a message in the messages.properties file and now the login page
>>> will show a different error if someone's password is expired, their password
>>> has to be reset, etc.  So it is accomplishing what I wanted.  (The other
>>> good side to this is that the RESTful API sends this custom error code
>>> across the wire also.)  So I have been able to get it to do what I wanted,
>>> but I regret that the only way I could make it work was to "redo" these 3
>>> classes (someone else could probably have found a better way).
>>>
>>> Anyways, I will try to put in this JIRA request.
>>>
>>>
>>> On Thu, Sep 18, 2008 at 8:11 AM, Scott Battaglia <
>>> [email protected]> wrote:
>>>
>>>> On Fri, Sep 12, 2008 at 6:13 PM, Ryan Andreasen <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>> Our organization wants to be able to expire passwords, lock out
>>>>> accounts,
>>>>> etc.  I have seen some discussion about expiring passwords but haven't
>>>>> found
>>>>> a clear cut way of handling them.  Currently I am using the
>>>>> FastBindLDAPAuthenticator to do our ldap bind.  This is working great,
>>>>> except that if the login fails for any reason, the login page is shown
>>>>> again.  I need to be able to hook into the ldap exception coming back
>>>>> from
>>>>> the ldap bind, and depending on the ldap error code show them a
>>>>> different
>>>>> page or else the login page again.
>>>>>
>>>>> I have found that the actual ldap exception (NamingException) gets
>>>>> handled
>>>>> in the org.jasig.cas.adaptors.ldap.util.AuthenticatedLdapContextSource
>>>>> class.  However, it eats the NamingException and just throws a
>>>>> DataAccessResourceFailureException.  This exception percolates up to
>>>>> the
>>>>> FastBindLdapAuthenticationHandler, and then back up (eventually) to the
>>>>> AuthenticationViaFormAction class which populates the ErrorInstance,
>>>>> and
>>>>> sets the spring Event to error.   So I think I know how the current
>>>>> process
>>>>> is working and would like to get everyone's idea on the best way to
>>>>> hook in
>>>>> what I want.
>>>>
>>>>
>>>> It doesn't necessarily eat it, they should still be available in the
>>>> chain (i.e. exception.getCause().getCause()).  But yes, its not readily
>>>> obvious where it is.
>>>>
>>>>>
>>>>>
>>>>> Another question I had is how do you get the Errors (that are set in
>>>>> AuthenticationViaFormAction) in a different class?  Is there a way to
>>>>> get at
>>>>> them?
>>>>
>>>>
>>>> I believe by default the AuthenticationViaForm class just pulls out the
>>>> code and displays a message.  If you need better responsiveness than that,
>>>> you can open a JIRA enhancement request and w can try make that method
>>>> available for overriding such that you could implement custom behavior on
>>>> just that method.
>>>>
>>>> So essentially (and I'm saying this without looking), we'd set it up so
>>>> that you can have the thing that translates errors return specific events
>>>> and you can use the webflow to redirect to the appropriate views based on
>>>> the event name.  Not sure if it would work or how much effort it is to
>>>> update the code for this, but please put in a request and Ill take a look 
>>>> at
>>>> it ASAP (I'm going to allocate some time later anyway to work on open CAS
>>>> issues).
>>>>
>>>> Thanks
>>>> -Scott
>>>>
>>>>
>>>>>
>>>>>
>>>>> First, I would really like to not modify any of the cas-server-core
>>>>> code.  I
>>>>> guess I could basically write my own classes that do the same things as
>>>>> the
>>>>> FastBindLdapAuthenticationHandler & AuthenticatedLdapContextSource but
>>>>> that
>>>>> keeps the NamingException around rather than eating it, but this
>>>>> doesn't
>>>>> really sound right to me.
>>>>>
>>>>> Second, I would really like to somehow just hook into the spring
>>>>> webflow and
>>>>> insert my code to check the NamingException and redirect to the correct
>>>>> page
>>>>> based on it.
>>>>>
>>>>> I hope this makes sense; I am just looking to see what the best way to
>>>>> accomplish this might be.
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Hook-into-LDAP-Errors-tp19465040p19465040.html
>>>>> Sent from the CAS Users mailing list archive at Nabble.com.
>>>>>
>>>>> _______________________________________________
>>>>> Yale CAS mailing list
>>>>> [email protected]
>>>>> http://tp.its.yale.edu/mailman/listinfo/cas
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Yale CAS mailing list
>>>> [email protected]
>>>> http://tp.its.yale.edu/mailman/listinfo/cas
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Yale CAS mailing list
>>> [email protected]
>>> http://tp.its.yale.edu/mailman/listinfo/cas
>>>
>>>
>>
>> _______________________________________________
>> Yale CAS mailing list
>> [email protected]
>> http://tp.its.yale.edu/mailman/listinfo/cas
>>
>>
>
> _______________________________________________
> Yale CAS mailing list
> [email protected]
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas

Reply via email to