[xmlsec] request/complaint -- new error reporting feature
aleksey at aleksey.com
Wed Aug 28 19:40:15 PDT 2002
XMLSec is based on OpenSSL by itself and uses the errors reporting
by itself. As you can imagine, I do not want to deal with TLS either :)
Also there is one more advantage in looking into the OpenSSL errors
stack -- you will
get any crypto error from OpenSSL this way :)
BTW, there is a usefull flag 'xmlSecPrintErrorMessages' declared in
that allows you to control whether standard XMLSec errors handler prints
error to the LibXML2.
If it set to 0 then default XMLSec errors handlers reports errors to
Moultrie, Ferrell (ISSAtlanta) wrote:
>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.
>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
>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
>by OpenSSL since default XMLSec errors handler reports all errors to
>This gives you context (doc, etc.) and does not require any thread
>And I am not sure I get your idea about passing "context" to the
>function. This gives you *no* information about the current document
>Moultrie, Ferrell (ISSAtlanta) wrote:
>> 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
>>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?
>>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
>>Ferrell Moultrie (ferrell at iss.net)
>>Internet Security Systems, Inc.
>>6303 Barfield Road
>>Atlanta, Georgia 30328
>>Internet Security Systems -- The Power to Protect
>>xmlsec mailing list
>>xmlsec at aleksey.com
>xmlsec mailing list
>xmlsec at aleksey.com
More information about the xmlsec