Hello Scott,
Another point that can be considered while discussing exception handling and
logging in CAS.
In the class CentralAuthenticationServiceImpl:
public String createTicketGrantingTicket(final Credentials credentials)
The exception caught is an AuthenticationException and the exception thrown
is a TicketCreationException and to display the user name or additional
information this needs to be extracted from AuthenticationException object
and then given to TicketCreationException as arguments to be displayed in
the method in AuthenticationViaFormAction. (Since there is no relation
between TicketException and AuthenticationException)
catch (final AuthenticationException e) {
//For getting user name:
throw new TicketCreationException(e,e.getArgs());
}
private final void populateErrorsInstance(final RequestContext context,
final TicketException e)
{
...
errors.reject(e.getCode(),e.getErrArg(), e.getCode());
}
This is just one case - where information required has to be transferred. In
such scenarios and those described by Marvin, improvements can be made.
-
Shivani.
On Tue, Nov 3, 2009 at 7:52 AM, Scott Battaglia <[email protected]>
wrote:
> Marvin,
>
> I think you've made a case for expanding the error codes available in the
> CAS protocol specification. I think the next steps on this is if you have
> any concrete proposals for CODE/description pairs, to propose it as an RFC
> and we can discuss on-list and at the next community call. And then if
> there's agreement, add it to the protocol.
>
> We've been pretty happy with the error code/descriptions since we added the
> one about service ticket matching (the number of questions about that has
> gone down to almost zero on list). It seems like you have additional
> insight into some user confusion that we're not seeing at RU or on this list
> so you may be in the best position to propose additional error
> codes/descriptions.
>
> We'll then need to work with our partners to internationalize any new ones.
>
> Cheers,
> Scott
>
>
> On Mon, Nov 2, 2009 at 4:41 PM, Marvin Addison <[email protected]>
> wrote:
>
>> >> The CAS 2 protocol supports
>> >> both a code and a description, but only the former is passed to
>> >> clients in many important cases.
>> >
>> > That's an incorrect statement. You didn't follow the code:
>>
>> You're absolutely right, sorry.
>>
>> > Again, I'm
>> > quite confident you've seen a CAS server validation error and seen the
>> > appropriate messages being returned and not the code.
>>
>> You're right, and it's my experience with these messages that is the
>> basis for the suggestion for providing more detail. I apologize for
>> getting off track with incomplete code review.
>>
>> I stand firm that the failure messages sent to clients can be vague.
>> Compare the specificity of what's logged versus the generality of the
>> message.properties template for ticket validation failure:
>>
>> if (serviceTicket == null) {
>> if (log.isDebugEnabled()) {
>> log.debug("ServiceTicket [" + serviceTicketId
>> + "] does not exist.");
>> }
>> throw new InvalidTicketException();
>> }
>>
>>
>> INVALID_TICKET=ticket ''{0}'' not recognized
>>
>>
>> In the former case I know exactly why it didn't validate, whereas in
>> the latter I have to guess whether it was a non-existent ticket or
>> expired ticket. In many cases there may be little difference, but if
>> you're troubleshooting a ticket expiration policy problem it could be
>> very helpful to know the difference.
>>
>> 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
