cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: svn commit: r582385 - in /incubator/cxf/trunk: common/common/src/main/java/org/apache/cxf/helpers/ rt/core/src/main/java/org/apache/cxf/transport/http/ systests/src/test/java/org/apache/cxf/systest/http_jetty/ systests/src/test/java/org/apache/cxf/syst...
Date Sat, 06 Oct 2007 00:31:16 GMT
On Friday 05 October 2007, Glen Mazza wrote:
> > +    @Test
> > +    public void testWSDLPublishWithCatalogs() throws Exception {
> > +        Endpoint ep = Endpoint.publish(null, new GreeterImpl());
> > +        try {
> > +            URL url = new
> > URL("http://localhost:9000/SoapContext/SoapPort?" +                 
> >             + "xsd=testutils/hello_world_schema2.xsd"); +           
> > assertNotNull(url.getContent());
> > +
> > +
> > +            url = new
> > URL("http://localhost:9000/SoapContext/SoapPort" +                  
> >        + "?xsd=testutils/hello_world_schema.xsd");
>
> I'm not sure what the code is doing here--but could this be a security
> bug?  Are you saying, just by typing in a network path
> ("testutils/..."), the user can download any xsd file from the server?
> Certain directories, such as within the WEB-INF directory of a WAR
> file, are not supposed to be directly callable externally.  I don't
> know how relevant that concern might be here though.

Shouldn't be an issue.   The first time a ?wsdl or ?xsd file is requested 
from the service, it resolves all the imports and creates a Map of 
original URL -> wsdl/schema.   If the requested wsdl/xsd is not in the 
map, it doesn't return anything.   It doesn't try to resolve anything 
outside the imports specified in the wsdl/schemas.

> > +            String result =
> > IOUtils.toString((InputStream)url.getContent()); +           
> > assertTrue(result.contains("xsd=testutils/hello_world_schema2.xsd"))
> >;
>
> testutils/hello_world_schema.xsd?  (unsure what is happening here)

If you look in testutils/src/main/resources/wsdl, I added a bunch of 
wsdls and schemas that use catalog entries (testutils/xxxxxxx.wsdl) 
instead of relative paths for all the imports.   What I'm testing is to 
make sure that all the imports that are handled by catalogs get properly 
replaced.   If you look at hello_world_schema.xsd in testutils, it has 
an import for "testutils/hello_world_schema2.xsd".   I'm making sure 
that we properly detected that it was handled by a catalog and then 
replaced with a resolvable URL.


> > +            url = new
> > URL("http://localhost:9000/SoapContext/SoapPort"
> > +                          +
> > "?wsdl=testutils/hello_world_messages_catalog.wsdl");
> > +            result =
> > IOUtils.toString((InputStream)url.getContent()); +
> > +assertTrue(result.contains("xsd=testutils/hello_world_schema.xsd"))
> >;
>
> testutils/hello_world_messages_catalog.wsdl?

Same as above.   It imports the schema via a catalog.



> > +        <wsdl:operation name="pingMe">
> > +            <wsdl:input name="pingMeRequest"
> > message="x1:pingMeRequest"/> +            <wsdl:output
> > name="pingMeResponse" message="x1:pingMeResponse"/> +           
> > <wsdl:fault name="pingMeFault" message="x1:pingMeFault"/> +       
> > </wsdl:operation>
>
> I'm not sure why we need to have the "name" attribute added to the
> wsdl:input and wsdl:output of these operations.  Since you're just
> restating their default values[1] anyway, it seems distracting to be
> including them here.  Apparently only the wsdl:faults need an explicit
> name.

Probably right.   I just took a bunch of wsdl's in the testutils, copied 
them, and changed them from using relative imports to using catalogs.  
Other than the imports, I left the rest alone.    Feel free to fix them 
since you have the Karma.  :-)

Thanks!
-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Mime
View raw message