I have a web service with a client written in Java. The service works behind a firewall and if the java client wants to consume the service, then its request is blocked because the request contains links. So the request contains validator references like this:
...<S:Envelope xmlns:S="http://schemas.xmlsoap.org/wsdl/"...
Shall I fix it in the wsdl file? That is the only place which contains this link:
<definitions targetNamespace="http://mycompany.com/" name="RentalServiceService"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:tns="http://mycompany.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
If I generate a client in .net from the wsdl file, then it does not put any link references into the request…
Thanks
Zoltan
Don’t remove namespaces from the XML message. Configure your firewall instead!
Normally, SOAP is friendly with firewalls because it piggybacks on top of HTTP. If you remove the namespaces from the XML you might get it through the firewall but the web service that must make use of the message might fail to parse it because you removed the namespaces from it. XML namespaces are important because they correctly identify the domain to which each element inside the message belongs to.
Just as an observation, the
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/wsdl/"...is a copy paste error of some sort?… or maybe part of the problem?! The namespace for the SOAP envelope should behttp://schemas.xmlsoap.org/soap/envelope/for SOAP 1.1 orhttp://www.w3.org/2003/05/soap-envelopefor SOAP 1.2.That aside, if the SOAP message is correctly formatted, it should pass through the firewall. If it doesn’t, then the solution is to configure the firewall properly and not mess with the SOAP message. Your network administrators should spend time understanding web services security and properly configure the firewall.
My suggestion would be to keep port 80 just for your users requests/responses from browsers and expose the service on a different port number with proper configurations. Maybe you could even set up a reverse proxy inside a DMZ to improve the web service security. With that, you won’t expose your internal web service server directly to the Internet.