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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] #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 > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas-dev >
_______________________________________________ cas-dev mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas-dev
