Can you sent use the code that produces the message causing the problems, including everything you do to configure Rampart? That should allow us to reproduce the problem.
Andreas On Thu, Dec 29, 2011 at 17:16, Jaime Hablutzel Egoavil <[email protected]> wrote: > Axis 1.6.1, rampart 1.6.1, axiom 1.2.12 > By the way I discovered that this problem only arises when using > > client.invokeRobust(new QName("http://client.mtom.sample";, "echo"), new > Object[]{dh}); > > And not with > > client.sendReceive(elem) > > And I'm looking that the first one creates > > <soapenv:Body > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > wsu:Id="id-2"><echo xmlns="http://client.mtom.sample";><arg0 > xmlns=""><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"; > href="cid:[email protected]" > /></arg0></echo></soapenv:Body> > > And the second one: > > <soapenv:Body > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; > wsu:Id="id-2"><ns1:echo > xmlns:ns1="http://client.mtom.sample";><arg0><xop:Include > xmlns:xop="http://www.w3.org/2004/08/xop/include"; > href="cid:[email protected]" > /></arg0></ns1:echo></soapenv:Body> > > > Anyway using the second it is working but with the first the stripped > xmlns="" makes the signature value different so the server after > canonicalization produces a different value and validation fails > > On Thu, Dec 29, 2011 at 4:31 AM, Andreas Veithen <[email protected]> > wrote: >> >> What are the Axis2, Rampart and Axiom versions that you are using? >> >> Andreas >> >> On Tue, Dec 27, 2011 at 23:18, Jaime Hablutzel Egoavil >> <[email protected]> wrote: >> > Hi I want to post an apparent bug when DOOM option is activated in the >> > client, so the SOAP message include xop:Include even when using >> > WS-Signature >> > and doesn't send the message in base64, this way getting advantage of >> > MTOM. >> > >> > When using DOOM the canonicalized data to create the digest is: >> > >> > <soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; >> > >> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; >> > wsu:Id="id-2"><echo >> > >> > xmlns="http://client.mtom.sample";><arg0>b3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ucHJvdmlkZXI9b3JnLmFwYWNoZS53cy5zZWN1cml0eS5jb21wb25lbnRzLmNyeXB0by5NZXJsaW4Kb3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ubWVybGluLmtleXN0b3JlLnR5cGU9amtzCm9yZy5hcGFjaGUud3Muc2VjdXJpdHkuY3J5cHRvLm1lcmxpbi5rZXlzdG9yZS5wYXNzd29yZD1hcGFjaGUKb3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ubWVybGluLmZpbGU9Y2xpZW50Lmprcw==</arg0></echo></soapenv:Body> >> > >> > But when DOOM is disabled the data is: >> > >> > <soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; >> > >> > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"; >> > wsu:Id="id-2"><echo xmlns="http://client.mtom.sample";><arg0 >> > >> > xmlns="">b3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ucHJvdmlkZXI9b3JnLmFwYWNoZS53cy5zZWN1cml0eS5jb21wb25lbnRzLmNyeXB0by5NZXJsaW4Kb3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ubWVybGluLmtleXN0b3JlLnR5cGU9amtzCm9yZy5hcGFjaGUud3Muc2VjdXJpdHkuY3J5cHRvLm1lcmxpbi5rZXlzdG9yZS5wYXNzd29yZD1hcGFjaGUKb3JnLmFwYWNoZS53cy5zZWN1cml0eS5jcnlwdG8ubWVybGluLmZpbGU9Y2xpZW50Lmprcw==</arg0></echo></soapenv:Body> >> > >> > Look at the difference in red color. This causes the digest value to be >> > different so the server gets confused and is unable to validate the >> > signature when using DOOM in the client. A workaround seems to be to use >> > only namespaced elements so the xmlns="" doesn't get generated never. >> > >> > I would like to know if someone has reached this problem when using MTOM >> > + >> > WS-Signature in axis 2. >> > >> > Other thing, DOOM option is not really well documented anywhere in axis2 >> > website and I just found that it was available to make real MTOM with >> > WS-Signature debugging the source code for three days u.u. >> > >> > Good bye >> > >> > >> > >> > -- >> > Jaime Hablutzel - 9-9956-3299 >> > >> > (tildes omitidas intencionalmente) >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Jaime Hablutzel - 9-9956-3299 > > (tildes omitidas intencionalmente) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
