I am trying to validate an XML message that is signed using XMLDSig. In order to create a message digest, I need to canonicalize the message first. It works fine, except that DOMNode::C14N() removes the second namespace from the code below:
<?xml version="1.0" encoding="UTF-8"?><DirectoryRes xmlns="http://www.idealdesk.com/ideal/messages/mer-acq/3.3.1" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" version="3.3.1">
<createDateTimestamp>2012-10-29T17:04:56.374Z</createDateTimestamp>
<Acquirer>
<acquirerID>0050</acquirerID>
</Acquirer>
<Directory>
<directoryDateTimestamp>2012-10-29T17:04:56.374Z</directoryDateTimestamp>
<Country>
<countryNames>Deutschland</countryNames>
<Issuer>
<issuerID>NLINGB2U152</issuerID>
<issuerName>Issuer Simulator</issuerName>
</Issuer>
</Country>
</Directory>
</DirectoryRes>
Canonicalizing the XML above results in the following XML:
<DirectoryRes xmlns="http://www.idealdesk.com/ideal/messages/mer-acq/3.3.1" version="3.3.1">
<createDateTimestamp>2012-10-29T17:04:56.374Z</createDateTimestamp>
<Acquirer>
<acquirerID>0050</acquirerID>
</Acquirer>
<Directory>
<directoryDateTimestamp>2012-10-29T17:04:56.374Z</directoryDateTimestamp>
<Country>
<countryNames>Deutschland</countryNames>
<Issuer>
<issuerID>NLINGB2U152</issuerID>
<issuerName>Issuer Simulator</issuerName>
</Issuer>
</Country>
</Directory>
</DirectoryRes>
The remote server I am testing with keeps this namespace when calculating the message digest, so validation obviously fails. I confirmed this issue by first adding the namespace back in before creating my own digest to compare to the digest embedded in the message (the signature was stripped from the XML code above prior to posting). The code however has to work with different servers, some of which may or may not add namespaces (they are not part of the specifications, but as far as I know just adding a redundant namespace declaration shouldn't hurt). I looked this up in the W3C XML C14N specs and they say root elements should always keep their namespaces, except empty default namespaces. The disappearing namespace is neither the default, nor empty, so I am not sure whether this is a bug in DOMNode::C14N() or whether I overlooked something important.
The c14n spec suggests that extra namespaces don't make it into the canonicalized form.
If you made use of ns2, etc they should make it down into the document emitted by ->c14n.
You probably already figured this out, but since you are communicating with iDEAL you have to follow their "Signing iDEAL messages" remarks:
For the purpose of generating the digest of the main message, the inclusive canonicalization algorithm must be used6. This method of canonicalization of the main message is not (always) explicitly indicated in the iDEAL XML messages. For this reason this transform has not been included in the example messages in this document. Merchants are not required to explicitly indicate this transform in their messages.
Source: https://www.pronamic.eu/wp-content/uploads/sites/2/2016/06/Merchant-Integration-Guide-v3-3-1-ENG-February-2015.pdf
This can be confusing since the CanonicalizationMethod element algorithm is http://www.w3.org/2001/10/xml-exc-c14n#. For the digest however you always have to use https://www.w3.org/TR/2001/REC-xml-c14n-20010315. This canonicalization method algorithm will also leave the xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" in place.
In the xmlseclibs library, used a lot for iDEAL, is the http://www.w3.org/TR/2001/REC-xml-c14n-20010315 canonicalization method algorithm the default:
https://github.com/simplesamlphp/xmlseclibs/blob/v1.3.2/xmlseclibs.php#L872
Related
I am trying to setup a Soap connection between a server in php and a client in C. My server is using a working wsdl file and a class to add these methods. I can confirm with Wireshark that my client request is well received and correctly processed.
My issue is that the values of the XML element sent by the server cannot be read because the namespaces differs. By adding debug log in my client I have found that the error is :
Tags 'state' and 'ns2:state' match but namespaces differ
Issue :
The issue seems to be that the server response does not contain any default namespace :
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:ns1="http://www.w3.org/2005/08/adressing"
xmlns:ns2="http://www.namespace1/">
<env:Body>
<ns2:HelloResponse>
<state>OK</state>
<intElement>123</intElement>
</ns2:HelloResponse>
</env:Body>
</env:Envelope>
It looks like <state> and <intElement> are not in any namespace, so it can't match one of the client. In my Wsdl file, these element belongs to xmlns:s="http://www.w3.org/2001/XMLSchema"
What I tried :
Obvious solution is to add an namespace to these element, but I can't find a way to do it.
In my php server, I can modify any request that comes in but can't affect any response that comes out (or at least i didn't find how to do it).
2nd solution : Adding the namespace that describe these element to the Namespace struct in my client and then use the set_namespace() function.
But I couldn't manage to put them to work, please keep in mind that I am still new to the XML/Soap world, any help is appreciated.
As said before, the solution was to add the corresponding namespace to these element.
I managed to do it using ob_get_contents() and adding the namespace to <ns2:HelloResponse>. Using Wireshark was really useful for this kind of stuff.
I have a set of XLSX files that PhpSpreadsheet cannot load, because simplexml_load_string returns an empty SimpleXMLelement from (for instance) the workbook XML file.
The file has the following format, that can be loaded by simplexml after removing all occurrences of the x: namespace, and the declaration itself (that is, for instance, the <x:workbook> tag has been converted to <workbook>).
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<x:workbook xmlns:x15ac="http://schemas.microsoft.com/office/spreadsheetml/2010/11/ac" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:x15="http://schemas.microsoft.com/office/spreadsheetml/2010/11/main" xmlns:xr="http://schemas.microsoft.com/office/spreadsheetml/2014/revision" xmlns:xr6="http://schemas.microsoft.com/office/spreadsheetml/2016/revision6" xmlns:xr10="http://schemas.microsoft.com/office/spreadsheetml/2016/revision10" xmlns:xr2="http://schemas.microsoft.com/office/spreadsheetml/2015/revision2" mc:Ignorable="x15 xr xr6 xr10 xr2" xmlns:x="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
<x:fileVersion appName="xl" lastEdited="7" lowestEdited="4" rupBuild="23801" />
<x:workbookPr codeName="ThisWorkbook" />
<mc:AlternateContent xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006">
<mc:Choice Requires="x15">
<x15ac:absPath xmlns:x15ac="http://schemas.microsoft.com/office/spreadsheetml/2010/11/ac" url=".........." />
</mc:Choice>
</mc:AlternateContent>
<xr:revisionPtr revIDLastSave="0" documentId=".........." xr6:coauthVersionLast="46" xr6:coauthVersionMax="46" xr10:uidLastSave="{00000000-0000-0000-0000-000000000000}" />
<x:bookViews>
<x:workbookView xWindow="-120" yWindow="-120" windowWidth="29040" windowHeight="15840" xr2:uid="{00000000-000D-0000-FFFF-FFFF00000000}" />
</x:bookViews>
<x:sheets>
<x:sheet name="......" sheetId="1" r:id="rId1" />
</x:sheets>
<x:calcPr calcId="191029" />
</x:workbook>
I'm not sure the XML file is wrong, since the XLSX file(s) can be opened - for instance - with Libre Office. Anyway, have managed to load the file(s) hacking a simple minded function cleanup_xml() in Xlsx.php:
//~ http://schemas.openxmlformats.org/spreadsheetml/2006/main"
$xmlWorkbook = simplexml_load_string(
cleanup_xml($this->securityScanner->scan($this->getFromZipArchive($zip, "{$rel['Target']}"))),
'SimpleXMLElement',
Settings::getLibXmlLoaderOptions()
);
Maybe there is a proper/clean way to force simplexml API to load such files ?
edit:
I was wrong thinking all problems were gone after the cleanup_xml hack.
Seems that also the data rows XML file has problems, probably the same as above...
edit:
Indeed, I moved cleanup_xml() into XmlScanner::scan, to apply to every loaded XML, and now seems to work...
edit:
Seems the namespace declaration is correct, at least, from this simple example...
Then, I wonder why simplexml_load_string doesn't accept the format:
<x:workbook ... xmlns:x="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
....
</x:workbook>
while it apparently accepts
<workbook ... xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
....
<workbook>
edit
Have digged into simplexml API, this answer helped to understand the problem. Now I can try to rewrite my hackish cleanup_xml accounting for namespaces... Just wondering if PhpSpreadsheet offers a better way... seems strange this problem has been unnoticed before...
edit
ok, now I've found the bug report...
This appears to be a bug in PhpSpreadsheet.
Opening an XLSX file I created this week with a real copy of Microsoft Excel, the "workbook.xml" starts like this:
<workbook
xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"
xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="x15 xr xr6 xr10 xr2"
xmlns:x15="http://schemas.microsoft.com/office/spreadsheetml/2010/11/main"
xmlns:xr="http://schemas.microsoft.com/office/spreadsheetml/2014/revision"
xmlns:xr6="http://schemas.microsoft.com/office/spreadsheetml/2016/revision6"
xmlns:xr10="http://schemas.microsoft.com/office/spreadsheetml/2016/revision10"
xmlns:xr2="http://schemas.microsoft.com/office/spreadsheetml/2015/revision2">
This declares eight different namespaces that will be used in the document. One happens to be defined as the "default namespace", and the other seven are assigned prefixes - but all of that is just local to this specific file.
If we look at your XML document, we can see all the same namespaces in use, plus an extra one:
<x:workbook
xmlns:x15ac="http://schemas.microsoft.com/office/spreadsheetml/2010/11/ac"
xmlns:r="http://schemas.openxmlformats.org/officeDocumen/2006/relationships"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:x15="http://schemas.microsoft.com/office/spreadsheetml/2010/11/main"
xmlns:xr="http://schemas.microsoft.com/office/spreadsheetml/2014/revision"
xmlns:xr6="http://schemas.microsoft.com/office/spreadsheetml/2016/revision6"
xmlns:xr10="http://schemas.microsoft.com/office/spreadsheetml2016/revision10"
xmlns:xr2="http://schemas.microsoft.com/office/spreadsheetml/2015/revision2"
mc:Ignorable="x15 xr xr6 xr10 xr2"
xmlns:x="http://schemas.openxmlformats.org/spreadsheetml/2006/main">
The only difference is that the namespace "http://schemas.openxmlformats.org/spreadsheetml/2006/main" has been assigned prefix "x", rather than set as the default namespace, but that makes no difference to its meaning. A different library might label the namespaces completely differently, just because of the way it generates the XML:
<ns0:workbook
xmlns:ns0="http://schemas.openxmlformats.org/spreadsheetml/2006/main"
xmlns:ms1="http://schemas.openxmlformats.org/officeDocument/2006/relationships"
xmlns:ns2="http://schemas.openxmlformats.org/markup-compatibility/2006"
ns2:Ignorable="x15 xr xr6 xr10 xr2"
xmlns:ns3="http://schemas.microsoft.com/office/spreadsheetml/2010/11/main"
xmlns:ns4="http://schemas.microsoft.com/office/spreadsheetml/2014/revision"
xmlns:ns5="http://schemas.microsoft.com/office/spreadsheetml/2016/revision6"
xmlns:ns6="http://schemas.microsoft.com/office/spreadsheetml/2016/revision10"
xmlns:ns7="http://schemas.microsoft.com/office/spreadsheetml/2015/revision2">
As explained in this reference answer, SimpleXML's namespace handling is based around using the ->children() method to select the namespace you want to work with. The correct way to use this is to always specify the namespace URI you want, e.g. "http://schemas.openxmlformats.org/spreadsheetml/2006/main" or "http://schemas.microsoft.com/office/spreadsheetml/2016/revision10".
However, because the same program generally creates XML documents with the same choice of prefixes, it's easy to write incorrect code which relies on:
A particular namespace being the default, and therefore selected before you first call ->children()
Particular namespaces being bound to particular prefixes, and therefore selectable by looking up that prefix
The author of PhpSpreadsheet appears to have made both mistakes, meaning that when you try to load a document created by a different program, it doesn't find the namespaces it expects even though they're actually there.
I'm using an instance of PHPs built-in XMLReader to read some kind of user-generated XML file. Usually this XML files content starts like the following sample snippet, where everything works fine:
<?xml version="1.0" encoding="UTF-8"?>
<openimmo>
<uebertragung art="OFFLINE" umfang="VOLL" version="1.2.7" (...)
However, another user uses a different software to send and generate the XML file. The XML generated by this software starts like:
<?xml version="1.0" encoding="UTF-8"?>
<openimmo xmlns="http://www.openimmo.de" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openimmo.de openimmo.xsd">
<uebertragung art="OFFLINE" umfang="VOLL" version="1.2.7" (...)
Which causes my importer to fail with the following error:
XMLReader::read(): Element '{http://www.openimmo.de}openimmo': No matching global declaration available for the validation root.
I'm already doing validation by manually applying some XSD schema. The passed file follows the same schema, just explicitly specifies the xmlns attributes. How can I work around this issue? How can I tell XMLReader to just ignore that xmlns statement?
My code (simplified to the relevant sections) looks like the following snippet:
$reader = new XMLReader();
$success = #$reader->open($path);
if (!$success) { /* error handling */ }
$reader->setSchema($localOpenImmoXsdPath);
/* then starts reading and throws the above exception */
Namespace information is fundamental and there's no way an XML parser is going to ignore it.
Your options are either (a) send the file back to sender, saying it doesn't conform to the agreed schema, or (b) transform the file sent to you so that it does conform, by changing the namespace. That's a fairly simple XSLT transformation.
My immediate instinct was to look at the OpenImmo specs to see what they say about namespaces and schema conformance, but unfortunately access to the specs requires registration and licensing. Basically, either the specs allow both these formats, which would be a pretty shoddy spec, or they only allow one of them, in which case you shouldn't be accepting both.
I am using xsd2php library to parse XSD which describes API request body. Then using the same library (which itself uses jsm-serializer) I try to serialize objects:
$payload = new TrackRequest;
$searchCriteria = new SearchCriteriaAType;
$searchCriteria->addToConsignmentNumber(11111);
$payload->setSearchCriteria($searchCriteria);
$levelOfDetail = new LevelOfDetailAType;
$levelOfDetail->setSummary(true);
$payload->setLevelOfDetail($levelOfDetail);
Using basic serializer settings:
$serializerBuilder = SerializerBuilder::create();
$serializerBuilder->addMetadataDir(__DIR__ . '/../../metadata/Tracking', 'TNTExpressConnect\Tracking\XSD');
$serializerBuilder->setPropertyNamingStrategy(new IdenticalPropertyNamingStrategy);
$serializerBuilder->configureHandlers(function (HandlerRegistryInterface $handler) use ($serializerBuilder) {
$serializerBuilder->addDefaultHandlers();
$handler->registerSubscribingHandler(new BaseTypesHandler()); // XMLSchema List handling
$handler->registerSubscribingHandler(new XmlSchemaDateHandler()); // XMLSchema date handling
});
Serialization results in:
<?xml version="1.0" encoding="UTF-8"?>
<result>
<searchCriteria>
<account/>
<alternativeConsignmentNumber/>
<consignmentNumber>
<entry><![CDATA[11111]]></entry>
</consignmentNumber>
<customerReference/>
<pieceReference/>
</searchCriteria>
<levelOfDetail>
<summary>true</summary>
</levelOfDetail>
</result>
Regarding this results I have several questions:
Why the root element is <result> and not <TrackRequest>?
How to get rid of CDATA?
How to get rid of <entry> tags in favor of creating separate consigmentNumber tag for each entry?
How to replace <summary>true</summary> with self-closing tag <summary/>
I guess for every one of this cases I can create a dedicated handler, but maybe there is a built-in solution, which I overlooked in the documentation (maybe some config options that can be placed in yaml).
And if I have to create handlers maybe someone can point me the more sophisticated example, that explains how to do it right.
I'm not a big fan of annotations, so I would prefer to use separate config files.
Thank you in advance.
You should have a look ar the YAML Reference. A lot of things can be set up with the meta data files.
To change the "result" to "TrackRequest" add this line to the file:
Vendor\MyBundle\Model\ClassName:
xml_root_name: TrackRequest ## Changes the root element
To get rid of cdata in entry change the property:
properties:
entry:
xml_element:
cdata: false ## Add this to disable cdata tags
Just came accross the same problems as you did. I hope it helps.
Here's the code I'm using to generate the request headers:
$headers = array(
new SOAPHEADER($this->_ns,'username',$this->_username,false, $this->_actor),
new SOAPHEADER($this->_ns,'password',$this->_password,false, $this->_actor));
$this->_client->__setSOAPHeaders($headers);
This generates:
<SOAP-ENV:Header>
<ns2:username SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next">test</ns2:username>
<ns2:password SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next">test</ns2:password>
</SOAP-ENV:Header>
That's all fine and dandy.
Here are my two questions:
The API doc requires that username be ns1:username and password be ns2:password. Mine are both ns2. First of all, what is the significance of the ns1|2? How can I fix this?
Second question is just is there a way to generate the same result by only calling SOAPHEADER() once?
Not easy to say whether the namespace makes a difference without seeing the declaration & knowing the service, but usually the receiving service looks only for the tags in that particular namespace. As you add $this->_ns to both of them, of course they'll be the same. You'll have to provide the proper namespace yourself (prefix doesn't matter, uri does).
Why would you want only 1 call?