To whom it may engage...
This is an automated request, but not an unsolicited one. For help
understanding the request please visit
http://gump.apache.org/nagged.html,
and/or contact [EMAIL PROTECTED]
Project xml-security has an issue affecting its community integration.
This issue affe
To whom it may engage...
This is an automated request, but not an unsolicited one. For help
understanding the request please visit
http://gump.apache.org/nagged.html,
and/or contact [EMAIL PROTECTED]
Project xml-security has an issue affecting its community integration.
This issue affe
To whom it may engage...
This is an automated request, but not an unsolicited one. For help
understanding the request please visit
http://gump.apache.org/nagged.html,
and/or contact [EMAIL PROTECTED]
Project xml-security has an issue affecting its community integration.
This issue affe
To whom it may engage...
This is an automated request, but not an unsolicited one. For help
understanding the request please visit
http://gump.apache.org/nagged.html,
and/or contact [EMAIL PROTECTED]
Project xml-security has an issue affecting its community integration.
This issue affe
As, while performing those steps, we haven't added a ds:Signature yet, we don't
have any dsig-xpath:XPath elements (nodes) in the Document. How can we apply
your second option?
Regards,
-R
Well,
I have found where the problem is:
In the CachedXPathFuncHereApi.eval() {
...
// Crea
Berin Lautenbach wingsofhermes.org> writes:
>
> Rafael wrote:
>
> > I have been examining the source code around the 'Transforms' implementation
and
> > it seems like only ns declarations in the context node(s) are used. That
would
> > mean that only Constants.SignatureSpecNS is somehow rec
What version of the xml-sec-library are
> you using?
> ItÂs the 1.1 or the CVS HEAD one?
>
> Raul
I am using 1_1_0 (april 2004).
The problem is easy to reproduce with the code at my first mail and with a
"intersect" with value "//bla:ToBeSigned".
You get:
org.apache.xml.security.transforms.Tra
trebor iksrazal wrote:
Our java client signs and encrypts the message, the
java server decrypts and verifies the recieved
message, forwards to an axis service which gets data,
the server then signs and encrypts the data, and
lastly the client decrypts and verifies the recieved
message. My questions
Scott Cantor wrote:
That's why I know in the latter case, the problem he's having comes up, but
I didn't understand why it would be a problem with inclusive, so maybe I'm
off base.
In this case canonicalisation should happen after the transform (as the
transform works on the nodeset). So I don't
Rafael wrote:
I have been examining the source code around the 'Transforms' implementation and
it seems like only ns declarations in the context node(s) are used. That would
mean that only Constants.SignatureSpecNS is somehow recognized.
From memory, that's correct. So I think what you need to d
The question is:
why XMLCipher.enryptData(Document context, Element element, boolean
contentMode) is private?
In our project we expect following encrypted data in SOAP envelope:
...
11 matches
Mail list logo