[xmlsec] request/complaint -- new error reporting feature

Moultrie, Ferrell (ISSAtlanta) FMoultrie at iss.net
Wed Aug 28 19:14:01 PDT 2002


Hmmm .. yes, I guess I'm more used to a C++ world where there's usually
some parent object that the library can retrieve the context information
from. Having to pass it through to all the functions would be a pain.
libxml2 as well as OpenSSL use the thread-local approach and I really
anticipated that would be how you would implement that. I guess I can do
the same thing within my code but TLS is a nasty trick in cross-platform
code and I usually prefer to see that done within libraries rather than
pushed back into the application space. If you don't think this belongs
in xmlsec itself, I'll probably just use the openssl error stack. If
nothing else, that should handle the cascade of errors that seem to
occur when anything goes wrong deep inside xmlsec. The first error is
the most meaningful, the last is rather generic. Having a stack will let
me work around that nicely. Thanks for the consideration .. your
existing plan is adequate, just not what I had mentally expected based
on my experience with other libraries.
Ferrell

-----Original Message-----
From: Aleksey Sanin [mailto:aleksey at aleksey.com] 
Sent: Wednesday, August 28, 2002 9:39 PM
To: Moultrie, Ferrell (ISSAtlanta)
Cc: xmlsec at aleksey.com
Subject: Re: [xmlsec] request/complaint -- new error reporting feature


There are some problems with "void* context" parameter for error 
reporting function
and the main one is that if you really want to do it then you have to 
pass this "context"
paramer in *all* your functions (which is ugly :( ).
In real life there are few possible workarounds and the most popular one

is to use
thread context storage (per thread specific values). For example, 
OpenSSL does this
for its error reporting.
Another option would be to wait till the end and analize the errors 
stack provided
by OpenSSL since default XMLSec errors handler reports all errors to 
OpenSSL.
This gives you context (doc, etc.) and does not require any thread 
context storage.

And I am not sure I get your idea about passing "context" to the 
xmlSecErrorsSetCallback()
function. This gives you *no* information about the current document 
processed.

Aleksey.


Moultrie, Ferrell (ISSAtlanta) wrote:

>Aleksey:
>  Ok .. I'm trying to use the new xmlsec error reporting feature.
>There's one thing that was apparently overlooked -- I can only register
>one global static function and there's no context reported to that
>function (only file, line, func, reason, and msg -- none of which I
>control). So, when my callback function gets control, it has no way to
>know which document the error relates to (I have multiple documents
open
>for verification operations concurrently). 
>  The libxml2 error function registration while not giving me nearly as
>much/nice information as yours does -- at least allows me to register a
>(void*) context pointer which I can use to figure out the document
>context to which the call applies. 
>  Have I missed something obvious (again!) or was this an oversight?
Any
>thoughts about fixing/improving it if so? Passing a context pointer on
>the xmlSecErrorsSetCallback() method and then supplying it as a new
>parameter to the callback function would be a quite sufficient
solution,
>IMO.
>Thanks!
>  Ferrell
>
>=====================================
>Ferrell Moultrie (ferrell at iss.net)
>Software Engineer
>
>Internet Security Systems, Inc.
>6303 Barfield Road
>Atlanta, Georgia 30328
>Phone:  404-236-2600
>Direct: 404-236-2849
>Fax:    404-236-2632
>http://www.iss.net
>
>Internet Security Systems -- The Power to Protect
>=====================================
>_______________________________________________
>xmlsec mailing list
>xmlsec at aleksey.com
>http://www.aleksey.com/mailman/listinfo/xmlsec
>  
>




More information about the xmlsec mailing list