Thank for a prompt reply Aleksey.
On 24 January 2014 17:55, Aleksey Sanin <[email protected]> wrote: > Hi Krzysztof, > > Let me try to answer your questions one-by-one > > * IO handlers > > To handle the context, you can use a trick with thread local storage: > you can set your data in TLS before calling XMLSec, then use this > data in the context, and cleanup after XMLSec is done. > Um, sounds like a thread-specific global variable. This answers my question that there's no way to pass any context to IO callbacks nor replace the IO transformation :) It's a bit nasty hack which may make it hard to justify transitioning to xmlsec but I'll probably give it a go anyway. > * additional certificate/key checks > > You can also look at implementing a custom keys store > > http://www.aleksey.com/xmlsec/api/xmlsec-keysmngr.html#XMLSECKEYSTOREKLASS > > The findKey method is the one you need. > Yes, I looked at it initially at the example [1]. But I couldn't see how it'd help me hook in with my additional `X509_VERIFY_PARAM` settings. Now I can see that by making all plumbing through xmlsec key related structs (similarly to what happens in `src/openssl/x509vfy.c`) I can provide my own certificate verification procedure. > > * registering transformation URIs > > Easy one :) > > > http://www.aleksey.com/xmlsec/api/xmlsec-transforms.html#XMLSECTRANSFORMIDSREGISTER > > Ah, right. Just find the standard transformation equivalent for my legacy URI, "copy" it, replace its `href` and re-register. Cheers, Kris [1] http://www.aleksey.com/xmlsec/api/xmlsec-custom-keys-manager.html
_______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
