 |
 |
On Thu, Oct 21, 2010 at 07:14:46PM -0400, Scott Cantor wrote: > Yes, and I'm dealing internally with at least that many layers in my own > code. There are also specific requirements to *prevent* errors from being > seen because there's client-side failover support for SAML queries when the > authority advertises multiple endpoints. And there's chaining of attribute > sources themselves on top of that. The solution here is to decorate the > normal API for resolving attributes with optional status information from > the underlying components. Yes, that works. If there are context handles then you can use those to stash trace/debug/error information too. > > The first problem is dealing with the error handling limitations of each > > layer, which often requires extensive surgery (and API extensions) or > > outright new APIs (too much work). The second is that often apps can > > only pass detailed error information to users, as opposed to acting on > > detailed error information to remediate the situation (often there's > > nothing they could do to remediate the situation). But one must not > > underestimate the value of making detailed error information available > > to the user. > > No, but one must not overestimate it either. It needs to be visible, but to > the person resolving the problem, not necessarily to the user. In this case, > it's always visible in my logs, but I can add some additional bandwidth to > my APIs if people want to do more. Consider a typical ssh(1) error message when using "gss keyex", where the server's GSS error token says "I don't have that key version": the client should delete the old service ticket and tell the user to retry (if not retry automatically). Versus an error saying "I don't have keys for the requested service principal", in which case the client should tell the user to call file a ticket with the relevant helpdesk. There's a fair number of such error codes, and the main thing is to translate them into messages that are useful to the user or into remediation actions. For Kerberos this means that there should be two error strings, not one, for a number of error codes, because the error code->string context (client-side vs. server-side) matters. (I realize I'm just spouting generic advice here, and that it's not necessarily useful. But do note that we, in Solaris engineering, very much care about handling these sorts of errors in reasonable ways. I would like to see such ideas spread, so that we don't have new UI disasters such as the libldap situation that I described.) Nico --