[19027] in Kerberos_V5_Development
Re: Make error messages more useful: add a URI
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Oct 3 14:48:00 2014
Date: Fri, 3 Oct 2014 13:47:44 -0500
From: Nico Williams <nico@cryptonector.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <20141003184743.GC4981@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.GSO.1.10.1410031159250.27826@multics.mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Fri, Oct 03, 2014 at 12:07:34PM -0400, Benjamin Kaduk wrote:
> On Thu, 2 Oct 2014, Nico Williams wrote:
> > [libdefaults]
> > err_fmt = %E. Please see https://whatever.example/%N
> >
> > [...]
>
> I'm slightly concerned that supporting more %foo tokens for expansion
> would lead to an API explosion at call sites that set the error message.
> Adding N new optional positional parameters to krb5_set_error_message to
> hold all the possible values seems bad. Adding a single struct parameter
> to hold them all might be bad. A single parameter to the head of a linked
> list of containers holding type-tagged data is probably too complex;
> adding separate routines to add a single expandable value to the context
> might make call sites too noisy, depending on how common it is to set
> extra attributes.
>
> Did you have anything in particular in mind?
I hadn't thought about it much, but here's the list of tokens I
envision:
%E -> normal error message
%N -> error code (numeric)
%S -> error code (symbolic; string)
%A -> additional context information (string)
The last item would require changes at various krb5_set_error_message()
call sites, and might not materialize. Things I'd expect to be included
in it, if it happens at all, might be: relevant environment variables
and values, and the ccache name (if defaulted).
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
