Just wanted to let you know that tonight's build will incorporate both those fixes... the JARs you'd need are muse-core and muse-wsa-soap.
Dan Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/12/2007 02:06:54 PM: > I actually used toString(xml, true, false) since it was the indentation > which was the problem, not the <?xml> header. > > Don't forget to fix the ElementSerializer as well. It breaks the > signature by changing the namespace prefix. I am not sure what the > correct fix is there since other Muse code might depend on the current > behavior. > > I'll let you know if I find problems in Axis, but I'll go with the mini > engine for now. Lots of work to do. :-) > > Thanks, > Erik > > > Daniel Jemiolo wrote: > > Thanks for the SoapClient fix - that's a tricky one. I knew were weren't > > adding actual whitespace text nodes to the DOM, so I couldn't fathom why > > there would be more whitespace on the outgoing message. I'll fix it so > > that we use toString(xml, false, false), which will disable indentation. > > > > Please update us if you find a similar problem in the Axis2/Axiom code > > that accounts for the remaining issues. > > > > Dan > > > > > > > > Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/10/2007 05:58:54 AM: > > > > > >> Daniel, > >> > >> I have looked for the source of the indentation. In > >> SimpleSoapClient.java at line 247: > >> > >> byte[] soapBytes = XmlUtils.toString(soapRequest).getBytes(); > >> > >> This does indentation, so it will break the message on the client side > >> before it is sent. However, fixing this didn't take care of the problem, > >> so something else does indentation as well. > >> > >> I made a search for the use of XmlUtils.toString in the muse source and > >> I got 45 hits. Most seemed ok, but I didn't go through all of them. > >> > >> I have not looked at the Axis code, which might also do indentation. > >> > >> I need to work on some other things today, but I will look into this > >> later. If Axis is the source of the remaining problems, using the mini > >> engine might solve it for me. I will try the mini engine later when I > >> have time again. > >> > >> Regards, > >> Erik > >> > >> > >> Daniel Jemiolo wrote: > >> > >>> From a Muse perspective, the only time we add indentation is in > >>> XmlUtils.toString(), which is used if you turn on SOAP tracing > >>> > > (log-level > > > >>> = FINE in muse.xml). This just makes it easier to read the log file. > >>> > > You > > > >>> can stop the indentation all together by using this version of > >>> XmlUtils.toString(): > >>> > >>> http://ws.apache.org/muse/docs/2.2. > >>> > > 0/javadoc/org/apache/muse/util/xml/XmlUtils.html#toString(org.w3c.dom.Node,% > > > >> 20boolean,%20boolean) > >> > >>> The point is that, from a Muse perspective, we don't add any > >>> > > additional > > > >>> whitespace nodes/indentation when processing the message - it just > >>> > > happens > > > >>> when we trace. If you look in the Axis2 service code, we just take the > >>> > > > > > >>> SOAP body as it comes from Axis2 (in Axiom form), convert it to DOM, > >>> > > and > > > >>> hand off the DOM tree to your method: > >>> > >>> > >>> > > http://svn.apache.org/viewvc/webservices/muse/trunk/modules/muse-platform- > > > >> axis2/src/org/apache/muse/core/platform/axis2/AxisIsolationLayer.java? > >> revision=522017&view=markup > >> > >>> The Axiom -> DOM conversion is pretty straightforward - I could > >>> > > understand > > > >>> if we had *missed* something in the copying, but *adding* new things > >>> > > would > > > >>> be hard. > >>> > >>> Does this problem happen if you use the Mini SOAP engine (-j2ee mini)? > >>> > > If > > > >>> not, the problem may be with Axiom/Axis2. I've noticed that, like Axis > >>> > > > > > >>> 1.x, there are still cases where Axis2 adds in prefix/namespace > >>> declarations, and so the addition of blank/whitespace text nodes does > >>> > > not > > > >>> seem impossible. > >>> > >>> > >>> > >>> Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/09/2007 02:51:06 AM: > >>> > >>> > >>> > >>>> Daniel Jemiolo wrote: > >>>> > >>>> > >>>>> Can you give an example of the changing of XML prefixes? This was > >>>>> > >>>>> > >>> actually > >>> > >>> > >>>>> a major problem for us with the various SOAP engines we targeted > >>>>> > >>>>> > >>> (because > >>> > >>> > >>>>> WSRF is very dependent on prefixes staying the same), so we make > >>>>> > > sure > > > >>> not > >>> > >>> > >>>>> to modify prefixes in the request handling. Let me know what's > >>>>> > >>>>> > >>> happening. > >>> > >>> > >>>>> Also, are you signing things as part of the operation > >>>>> > > implementations? > > > >>> > >>>>> Normally this is done with something like WSS4J, which you can > >>>>> > > enable > > > >>> as > >>> > >>> > >>>>> an Axis2 handler (so the envelope will be completely finished when > >>>>> > > you > > > >>> > >>>>> sign or validate it). > >>>>> > >>>>> Dan > >>>>> > >>>>> > >>>>> > >>>>> Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/08/2007 01:52:42 PM: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Hello, > >>>>>> > >>>>>> I am using Apache Muse 2.2.0 for implementing a web service. I need > >>>>>> > > > > > >>> to > >>> > >>> > >>>>>> pass digitally signed XML documents to the service. The problem I > >>>>>> > >>>>>> > >>> have > >>> > >>> > >>>>>> is that Muse re-indents the XML and changes namespace prefixes. > >>>>>> > > This > > > >>>>>> breaks the signatures. > >>>>>> > >>>>>> Is this a bug, feature or do I need to reconfigure muse somehow? I > >>>>>> > >>>>>> > >>> tried > >>> > >>> > >>>>>> to search the web, this list and the bug tracking system, but I > >>>>>> > >>>>>> > >>> couldn't > >>> > >>> > >>>>>> find anything. > >>>>>> > >>>>>> Regards, > >>>>>> Erik > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> The signature is for an XML document which is signed standalone. I am > >>>> not signing the WS invocation itself, rather I am transmitting a > >>>> document which has been previously signed. So WSS4J is not what I am > >>>> looking for here. > >>>> > >>>> The schema for the messages looks like this: > >>>> > >>>> <xsd:schema elementFormDefault="qualified" > >>>> targetNamespace="http://sics.se/my-stuff";> > >>>> > >>>> <xsd:element name="AddPolicy"> > >>>> <xsd:complexType> > >>>> <xsd:sequence> > >>>> <xsd:element ref="saml:Assertion" /> > >>>> </xsd:sequence> > >>>> </xsd:complexType> > >>>> </xsd:element> > >>>> > >>>> <xsd:element name="AddPolicyResponse" type="xsd:anyURI"/> > >>>> </xsd:schema> > >>>> > >>>> I use wsdl2java to generate a client proxy which has the following > >>>> > >>>> > >>> method: > >>> > >>> > >>>> URI addPolicy(Element assertion) throws SoapFault; > >>>> > >>>> I read my signed document from disc and parse it into a DOM. I pass > >>>> > > the > > > >>>> document element of this DOM to the above method. The document looks > >>>> like this (fragments only since it is quite long): > >>>> > >>>> <?xml version="1.0" encoding="UTF-8"?> > >>>> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > >>>> ID="ID_191adef5-f5a9-40b6-a0c1-c23ca7de3c6c" > >>>> IssueInstant="2007-04-08T13:56:13Z" Version="2.0"> > >>>> <saml:Issuer > >>>> Format="http://www.w3.org/2001/XMLSchema#string";>...</saml:Issuer> > >>>> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";> > >>>> ... > >>>> <ds:Reference URI="#ID_191adef5-f5a9-40b6-a0c1-c23ca7de3c6c"> > >>>> ... > >>>> </ds:Signature> > >>>> <saml:Statement > >>>> xmlns:xacml-saml="urn:oasis:xacml:3.0:saml:assertion:schema:os" > >>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > >>>> xsi:type="xacml-saml:XACMLPolicyStatementType"> > >>>> <xacml:Policy xmlns="urn:oasis:names:tc:xacml:3.0:schema:os" > >>>> xmlns:xacml="urn:oasis:names:tc:xacml:3.0:schema:os" PolicyId="..." > >>>> RuleCombiningAlgId="..." Version="1.0"> > >>>> <xacml:Target> > >>>> <xacml:DisjunctiveMatch> > >>>> ... > >>>> > >>>> > >>>> On the server side wsdl2java generates the following: > >>>> > >>>> public URI addPolicy(Element Assertion) throws Exception { > >>>> .... > >>>> } > >>>> > >>>> When I receive the document here it doesn't look right. notice the > >>>> prefix "pfx3" and the excessive amount of indentation: > >>>> > >>>> <pfx3:Assertion ID="ID_191adef5-f5a9-40b6-a0c1-c23ca7de3c6c" > >>>> IssueInstant="2007-04-08T13:56:13Z" Version="2.0"> > >>>> > >>>> > >>>> > >>>> <saml:Issuer > >>>> > >>>> > >>>> > > Format="http://www.w3.org/2001/XMLSchema#string";>...</saml:Issuer><ds:Signature> > > > >>>> .... > >>>> > >>>> <ds:SignedInfo> > >>>> </ds:KeyInfo></ds:Signature><saml:Statement > >>>> xmlns:xacml-saml="urn:oasis:xacml:3.0:saml:assertion:schema:os" > >>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > >>>> type="xacml-saml:XACMLPolicyStatementType"> > >>>> > >>>> <xacml:Policy PolicyId="..." RuleCombiningAlgId="..." > >>>> Version="1.0"> > >>>> > >>>> > >>>> <xacml:Target> > >>>> > >>>> > >>>> > >>>> <xacml:DisjunctiveMatch> > >>>> > >>>> > >>>> xsi:type has also been changed to just type in the saml:Statement > >>>> > >>>> > >>> element. > >>> > >>> > >>>> I got the above document by encoding the received Assertion element > >>>> > > to a > > > >>>> file in the capability implementation. I used the apache xml-security > >>>> canonicalizer for the encoding: > >>>> > >>>> Canonicalizer canon = Canonicalizer.getInstance > >>>> (Canonicalizer.ALGO_ID_C14N_WITH_COMMENTS); > >>>> FileOutputStream fouts = new > >>>> > >>>> > >>> FileOutputStream("/tmp/tete2.xml"); > >>> > >>> > >>>> fouts.write(canon.canonicalizeSubtree(Assertion)); > >>>> fouts.close(); > >>>> > >>>> I don't think it is the canonicalizer which messes up the file. I > >>>> > > also > > > >>>> tried to use the Muse XmlUtils class for this encoding, in which case > >>>> the document looks different from above. (The indentation is > >>>> > > prettier.) > > > >>>> I am using the axis2 engine and I deploy the war in tomcat 5 on > >>>> > > Fedora > > > >>>> Core 6 Linux. > >>>> > >>>> Thanks for your assistance, > >>>> Erik > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
