PHP 5.1. to 5.2. and it stopped working....

431 views
Skip to first unread message

Mike

unread,
Apr 2, 2008, 1:00:42 AM4/2/08
to xmlseclibs
After moving an application from PHP 5.1. to 5.2. I ran into a probelm
where my secure soap requests where failing at the service provider.

After a bit of digging about I discovered the part of xmlseclibs.php
that chooses the canonicalization method based on the version of
PHP. After forcing the code to run with its own canonicalization
method (rather than the DOMNode::C14N() method) the application worked
again. So what's up with the DOMNode::C14N method?

Looking in the log files I saw [something like] this (several times
per request):

[...]Relative namespace UR is invalid here : java in [...]/
xmlseclibs.php on line 587
[...]Internal error : checking for relative namespaces in [...]/
xmlseclibs.php on line 587
[...]Internal error : processing docs children list in [...]/
xmlseclibs.php on line 587

I *think* what is happening is that DOMNode::C14N() is failing and
passing back nothing when the script is signing elements of the
request. Therefore the signiture of the elements does not match (by
the time it gets to the service provider). I thought that maybe this
was a bug and that DOMNode::C14N() should only be passed entire
documents and not elements, but then I read here that at least some of
you have it workinf fine with 5.2.

Any ideas? Cheers

Rob Richards

unread,
Apr 2, 2008, 6:09:43 AM4/2/08
to xmlse...@googlegroups.com

The C14N method is the true correct way to canonicalize a document
written to the full specs of exclusive and inclusive canonicalization.
Depending upon what you are passing, it is possible that additional
options might be needed to be passed to the method or the request
contains some incorrect markup that the older canonicalization routine
does not check for.
Based on that error you get though, it looks like one of the namespace
URIs in your document is not a valid namespace.

Can you provide a serialized version of the SOAP request prior to it
being canonicalized? Would be the easiest way to tell what's wrong
and/or fix any bugs. Please tar or zip the request so the raw request is
provided and no whitespaces are lost/altered during transport or from
mail clients.

Rob

Mike

unread,
Apr 2, 2008, 7:19:39 PM4/2/08
to xmlseclibs
Hi Rob,

I will work on getting the soap request available, due to the nature
of the system I will not be able to simply post it without jumping
through a couple of hoops here first.

I too thought that there may be a way to tell DOMNode::C14N about
namespaces we have to use etc so that it wouldn't fail, but I can't
find any docs about it. The best I found was:

http://docs.php.net/manual/en/migration52.methods.php

Has anyone got more info on this method? It has a 'ns_prefixes'
parameter which sounds interesting.

Thanks for the response.

Mike

Mike

unread,
Apr 2, 2008, 11:07:52 PM4/2/08
to xmlseclibs
OK. Turns out that there was an 'error' in some of the ns attributes
and once I fixed them the code worked. Trouble is the target service
now can't validate the document as I have made alterations. So I will
either have to force xmlseclib to use the old code, or try and get the
service provider to change the WSDL file.

Thanks

Rob Richards

unread,
Apr 3, 2008, 7:09:48 AM4/3/08
to xmlse...@googlegroups.com
Are you able to provide any of the values in error? I'm curious to know
if this is a bug in the underlying library or if the service provider
has a bug with their usage? If it's the latter, I would think you
wouldn't have a problem with getting them to change. BTW: Have you run
either the SOAP request or their WSDL through any validator to at least
check for well-formedness?

Rob

Mike

unread,
Apr 3, 2008, 6:40:40 PM4/3/08
to xmlseclibs
> Are you able to provide any of the values in error?

Yeah I found that changing all namespace attributes that contained
"java:.." to "java://..." worked.

> I'm curious to know if this is a bug in the underlying library or if the service provider
> has a bug with their usage?

Yeah me too. The WSDL was created by an 3rd party app (ie not by hand
or in house) so they were a little surprised when I mentioned that it
failed in our system.

> BTW: Have you run either the SOAP request or their WSDL through any validator to at least
> check for well-formedness?

Yeah I ran the original WSDL through the W3C Markup Validator and it
passed ok. (Is that enough?)

Am I correct in saying that while the WSDL file might be valid XML and
valid as a WSDL, it still might not be able to run through the C14N
method (as C14N spec disallows relative namespaces for example).

Am I also correct to think that the script here uses the C14N method
simply to create a string of a XML document stored in a class? Or is
there more to it than that?

Mike

unread,
Apr 8, 2008, 2:07:28 AM4/8/08
to xmlseclibs
Here is some example code that highlights the issues I am having with
the C14N() method. I grabbed this XML directly from a XML Server
Software vendors site, and the function fails....

<?php

// XML from http://edocs.bea.com/wls/docs70/webserv/customdata.html

$xml_doc = <<<EOD
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:stns="java:examples.newTypes"
attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="java:examples.newTypes">
<xsd:complexType name="EmployeeBean">
<xsd:sequence>
<xsd:element name="name"
type="xsd:string"
nillable="true"
minOccurs="1"
maxOccurs="1">
</xsd:element>
<xsd:element name="id"
type="xsd:int"
minOccurs="1"
maxOccurs="1">
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
EOD;

$doc = new DOMDocument();
$doc->loadXML( $xml_doc );

$original = $doc->saveXML();
print htmlentities($original);

print "<hr>";

$c14n = $doc->C14N();
print htmlentities($c14n);

?>

So who do you think is in the wrong here, the XML or the method?

Cheers

Rob Richards

unread,
Apr 8, 2008, 12:34:41 PM4/8/08
to xmlse...@googlegroups.com
Hi Mike,

I'm going to check on this a bit more, but am pretty sure that its due
to the fact that libxml2 does not have full support or handling URIs
based on RFC 3986, but rather the older RFC 2396. For now you will need
to use my hand coded version of C14N until that gets addressed. It is
something on the todo but not a high priority.

Rob

Mike

unread,
Apr 8, 2008, 7:04:55 PM4/8/08
to xmlseclibs
> I'm going to check on this a bit more, but am pretty sure that its due
> to the fact that libxml2 does not have full support or handling URIs
> based on RFC 3986, but rather the older RFC 2396.

Yes I think you are right I have found talk about this issue in the
Gnome XML mailing lists in regard to the webDAV "DAV:" namespace which
does the same thing.

(I know you know about this Rob, but for everyone else... )

xml mailing list posts of interest:

http://mail.gnome.org/archives/xml/2005-March/msg00114.html
http://mail.gnome.org/archives/xml/2005-March/msg00121.html
http://mail.gnome.org/archives/xml/2006-February/msg00222.html

"Long term impact would be it probably would never get done..."

Seems you were right Rob!
Reply all
Reply to author
Forward
0 new messages