-
Bug
-
Resolution: Won't Do
-
Major
-
None
-
jbossws-cxf-5.1.5.Final
We have Wildfly 10 configured behind NGINX as a reverse proxy for handling the SSL requirements of the web service. Wildfly serves everything as plain HTTP and NGINX handles the HTTPS side of the request. The webservices subsystem is configured to rewrite the uri using https schema. The XSD schema location referenced inside the WSDL is rewritten to use https. However, any other XSD's scheme location that is referenced by the first XSD is not changed to use https.
The URI rewriting for the SOAP address and the schema location of the XSD included in the WSDL works correctly.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://example.systems/webservices/" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:ns1="http://example.co.za/claim/zmf" attributeFormDefault="unqualified" elementFormDefault="unqualified" targetNamespace="http://example.systems/webservices/"> <xs:import namespace="http://example.co.za/claim/zmf" schemaLocation="https://dev.example.ws:8081/webservices/Claim?xsd=ZietoClaim_2_1.xsd"/> <!-- xml omitted --> <wsdl:service name="ClaimService"> <wsdl:port binding="tns:ClaimServiceSoapBinding" name="ClaimWSPort"> <soap12:address location="https://dev.example.ws:8081/webservices/ZMF"/> </wsdl:port> </wsdl:service>
The XSD referenced inside the WSDL contains 2 more import statements to import 2 more XSD's. This is however where the problem starts. In the extract below you will notice that the schema location uses http and not https for the other 2 XSD's.
<?xml version='1.0' encoding='UTF-8'?> <xsd:schema xmlns:zdt="http://example.co.za/claim/zmf/datatypes" xmlns:zcdt="http://example.co.za/common/datatypes" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://example.co.za/claim/zmf" elementFormDefault="qualified" targetNamespace="http://example.co.za/claim/zmf"> <xsd:import namespace="http://example.co.za/claim/zmf/datatypes" schemaLocation="http://dev.example.ws:8081/webservices/Claim?xsd=zmf_dt_2_1.xsd"/> <xsd:import namespace="http://example.co.za/common/datatypes" schemaLocation="http://dev.example.ws:8081/webservices/Claim?xsd=zdt_1_2.xsd"/>
[JBWS-4087] SOAP address rewrite for wsdl-uri-scheme=https for nested XML schema documents (XSD) referenced by the WSDL behind reverse proxy
rsearls Can this issue be marked as "Rejected" or still something we need to have a look ?
> What about doing the url rewrite when there is no absolute path/protocol included in the schemaLocation URL?
(e.g.
<xs:import namespace="http://example.co.za/claim/zmf" schemaLocation="ZietoClaim_2_1.xsd"/> <xsd:import namespace="http://example.co.za/claim/zmf/datatypes" schemaLocation="zmf_dt_2_1.xsd" /> <xsd:import namespace="http://example.co.za/common/datatypes" schemaLocation="zdt_1_2.xsd" />
In all these cases the schema location is required to be in the archive relative
to the declaring wsdl or schema. There are 2 testcases in jbossws that show this
modules/testsuite/shared-tests/src/test/java/org/jboss/test/ws/jaxws/jbws2412
modules/testsuite/shared-tests/src/test/java/org/jboss/test/ws/jaxws/jbws3870
> Alternatively, what if the schemaLocation URL uses the jbossws.undefined.host
(e.g.
<xsd:import namespace="http://example.co.za/claim/zmf/datatypes" schemaLocation="{jbossws.undefined.host}/zmf_dt_2_1.xsd" /> <xsd:import namespace="http://example.co.za/common/datatypes" schemaLocation="{jbossws.undefined.host}/zdt_1_2.xsd" /> }
You are using an incorrect assumption that every declaration such as (jbossws.undefined.host)
in a wsdl file is substituted with the corresponding real value. This is not
how a wsdl is processed. (There is no EE spec requirement to support this.) Only
the service's soap:address is evaluated for such a substitution. This feature is
wfly specific. It is a convenience wfly provides that allows the server admin to
declare the desired value in the server [1].
[1] https://docs.jboss.org/author/display/WFLY8/Web+services+configuration
Yes, as a convenience we often times use a bug number to declare a unique
directory for a new testcase.
Hi rsearls
I agree there can't be a generic solution and your use case for not doing it is valid. What about doing the url rewrite when there is no absolute path/protocol included in the schemaLocation URL? The bug report shows the rewritten URL's. The actual source WSDL and XSD make use of a relative path. The source WSDL (packaged as part of the application) contains something like:
<xs:import namespace="http://example.co.za/claim/zmf" schemaLocation="ZietoClaim_2_1.xsd"/>
And the referenced source XSD:
<xsd:import namespace="http://example.co.za/claim/zmf/datatypes" schemaLocation="zmf_dt_2_1.xsd" /> <xsd:import namespace="http://example.co.za/common/datatypes" schemaLocation="zdt_1_2.xsd" />
Alternatively, what if the schemaLocation URL uses the jbossws.undefined.host variable/placeholder (something like it) for forcing the same rewrite rules that are applied to the SOAP address location? Maybe something like:
<xsd:import namespace="http://example.co.za/claim/zmf/datatypes" schemaLocation="{jbossws.undefined.host}/zmf_dt_2_1.xsd" /> <xsd:import namespace="http://example.co.za/common/datatypes" schemaLocation="{jbossws.undefined.host}/zdt_1_2.xsd" />
I have no idea how to test for this. I can perhaps see if I can create a test case. Where is the best place for a test case?
Here https://github.com/jbossws/jbossws-cxf/tree/master/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf using the bug number as a package name?
Is there any documentation available with pointers that could make it easier to write the test case?
Nico Schlebusch (Inactive)
added a comment - - edited Hi rsearls
I agree there can't be a generic solution and your use case for not doing it is valid. What about doing the url rewrite when there is no absolute path/protocol included in the schemaLocation URL? The bug report shows the rewritten URL's. The actual source WSDL and XSD make use of a relative path. The source WSDL (packaged as part of the application) contains something like:
<xs:import namespace= "http://example.co.za/claim/zmf" schemaLocation= "ZietoClaim_2_1.xsd" />
And the referenced source XSD:
<xsd:import namespace= "http://example.co.za/claim/zmf/datatypes" schemaLocation= "zmf_dt_2_1.xsd" />
<xsd:import namespace= "http://example.co.za/common/datatypes" schemaLocation= "zdt_1_2.xsd" />
Alternatively, what if the schemaLocation URL uses the jbossws.undefined.host variable/placeholder (something like it) for forcing the same rewrite rules that are applied to the SOAP address location? Maybe something like:
<xsd:import namespace= "http://example.co.za/claim/zmf/datatypes" schemaLocation= "{jbossws.undefined.host}/zmf_dt_2_1.xsd" />
<xsd:import namespace= "http://example.co.za/common/datatypes" schemaLocation= "{jbossws.undefined.host}/zdt_1_2.xsd" />
I have no idea how to test for this. I can perhaps see if I can create a test case. Where is the best place for a test case?
Here https://github.com/jbossws/jbossws-cxf/tree/master/modules/testsuite/cxf-tests/src/test/java/org/jboss/test/ws/jaxws/cxf using the bug number as a package name?
Is there any documentation available with pointers that could make it easier to write the test case? I have not been able to create a test case that calls the schemaLocation URL of the top level schema import in the wsdl. Can you provide a simple test case that demonstrates the issue?
I have concerns about attempting some type of generic remedy for this in jbossws.
It is possible to have a case where the wsdl is referencing some 3rd
party schema either in the parent wsdl or in the child schema file and
that address should not be converted in any way, because if the URL is
converted it will break the app. (e.g.
<xs:import namespace="http://another.apache.com/newest/stuff" schemaLocation="http://another.apache.com/future/product/schema/newest?xsd=newest_1_10.xsd" )
Rewriting of the schemaLocation URL seems like something that should be handled
by NGINX rules.
This can be rejected.