[cas-dev] Improvement suggestion for AbstractTicketValidationFilter

[Scott Battaglia]

Manfred,

If you can, please enter both of your emails to the list as issues in the
JIRA tracker: http://www.ja-sig.org/issues for the CAS client project.

Thanks!
-Scott

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

On Wed, Jul 9, 2008 at 3:03 AM, Manfred Duchrow <manfred.duchrow at md-cs.de>
wrote:

>  - Better support of user friendly error pages (instead of stack trace).
>    It is not possible to redirect from within the onFailedValidation() to
> an
>    error page which is more user friendly than a stack trace.
>    It would be helpful if onFailedValidation() would return a boolean
>    telling the caller method to return immediately (true) or continue
> (false).
>
>  - Method onFailedValidation() does not get the catched exception.
>    Therefore it is not possible to react differently on different
> exceptions.
>    At least there are two different reasons for getting a
>    TicketValidationException:
>    1) Communication with CAS server fails
>    2) The validation of the ticket fails (as returned by CAS server
> response)
>
>  - In case of a TicketValidationException method doFilter() either throws a
>    ServletException or continues executing the next filter in the chain.
>    The latter is probably a security hole and simply happens if init-param
>    exceptionOnValidationFailure=false ist set.
>
>
>  To enable redirect to an error page we modified the code of class
>  AbstractTicketValidationFilter in the following way:
>
>  Added new template method:
>    /**
>     * Template method that gets executed if validation fails.
>     * This method is called right after the exception is caught from the
> ticket
> validator
>     * but before {@link #onFailedValidation(HttpServletRequest,
> HttpServletResponse)} and before
>     * any of the processing of the exception occurs.
>     * If this method returns true it signals that validation failure has
> been
> handled
>     * sufficiently and the filter execution must be ended immediately.
>     * By returning false it signals that processing can be continued (as in
> previous versions).
>     *
>     * @param request the HttpServletRequest.
>     * @param response the HttpServletResponse.
>     * @param validationException The exception that was thrown to signal
> validation failure
>     * @return true to return immediately from filter execution, false to
> continue processing (default is false)
>     */
>    protected boolean handleFailedValidation(final HttpServletRequest
> request,
> final HttpServletResponse response,
>                 final TicketValidationException validationException )
>    {
>         return false ; // Default is to continue
>    }
>
>  Changed doFilter(..)
>            ....
>            } catch (final TicketValidationException e) {
>               // ---------------- START NEW CODE ------------------
>                if (handleFailedValidation(request, response, e))
>                {
>                        return ;
>                }
>               // ---------------- END NEW CODE ------------------
>
>                response.setStatus(HttpServletResponse.SC_FORBIDDEN);
>                log.warn(e, e);
>
>                if (this.exceptionOnValidationFailure) {
>                    throw new ServletException(e);
>                }
>            }
>            ....
>
> Generally I don't think it is a good approach to patch CAS code.
> Is it possible to get that or something similar into CAS Client?
>
> This refers to CAS Client 3.1.3
>
> Cheers,
>  Manfred
>
>
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080709/3531e71b/attachment.html