Thanks for that Aleksey
Initially I thought I had found a work-around, but I am now back looking
at the problem from square one again. Let me explain...
Another customer of the organisation I am communicating with was using
xmlsec at the command-line to do this, which is what led me down this
route initially.
It turns out that if the document (file) referred to in the <Reference>
URI attribute is in the _same directory_ as the SOAP document being
signed, xmlsec actually picks it up OK and includes its hash-value in
the <Reference> -> <DigestValue> element... problem solved!
(Apparently...) However, life is not so simple.
They are working on a Linux system, while I am cursed with being in
Windows. :-(
They are thus able to have files named "cid:/xxxxxxx/", while I am not
(no colons allowed in file-names in Windows!). So I changed the URI
attribute in my Reference element to just contain a file-name with no
"cid:" prefix, and that got things working as far as digitally signing
the whole thing with xmlsec was concerned. However now I am getting
messages through to the other party's back-end system, which are being
rejected because now _it_ can't identify the referred to document: it
seems that it insists on using that "cid:" scheme.
So...
I need to persuade xmlsec to recognise that "cid:" prefix and, in
effect, ignore it (if the referred-to file-name starts with "cid:",
replace that with nothing prior to trying to open the file).
I have got the xmlsec source, but up until now have just been using Igor
Zlatkovic's Windows binaries.
I need to (a) get xmlsec to compile in a Win32 environment and (b) know
where to make the changes in xmlsec (or perhaps one of its libraries) in
order to create a version which will do what I need.
I am not really a C/C++ programmer, but I can usually get by in pretty
much anything (I have been programming since about 1972 - Oh Lord!
That's 40 years! I'm getting too old for this!).
What compiler will I need and where do I find the code I will need to
change? And what build process do I need to go through? Is there a
make file or something similar?
Alternatively... what would it take to get somebody who actually knows
what (s)he is doing to do this for us? We don't have much in the way of
budget, but this is stopping a project that has months of work in it
dead in its tracks right now, so...
TIA
Mike Peat
On 14/09/2012 16:57, Aleksey Sanin wrote:
Mike,
You will probably need to write code to support "cid" URL scheme
and resolve references correctly to the MIME attachments:
http://www.aleksey.com/xmlsec/api/xmlsec-io.html
Aleksey
On 9/14/12 7:50 AM, Mike Peat wrote:
Hi
I am using xmlsec at the command line in an ebXML application. As you
probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its
messages. The message thus consists of multipart-MIME content in the
HTTP body: the first part being a SOAP document containing (among other
things) the Signature stuff and the second being an XML document which
is the business payload.
The Signature->SignedInfo in the SOAP document needs to contain two
<Reference> elements: one for the SOAP document itself (URI="") and one
for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content
ID of the second MIME part).
I am managing to successfully sign simple SOAP messages with no payload
(and hence no second <Reference> element), but I just can't work out how
to get xmlsec to sign both documents together. I have tried many
different ways, but to no avail. I am sure I am missing something
simple, but... :-(
Any help would be very much appreciated - I've been banging my head off
this brick wall for a week... and it is starting to really hurt! :-(
(That takes a while, because my brain is so dense, but even it starts
gets sore eventually!)
TIA
Mike Peat _______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
.
_______________________________________________
xmlsec mailing list
[email protected]
http://www.aleksey.com/mailman/listinfo/xmlsec
