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
