Two Questions:SOAPAction and RPCRouter security

[chuck clark <cc...@ziclix.com>]

Has anyone used/written any services which require the SOAPAction to be in the
header?
Right now I've been using the HTTPUtil.Post utility to send off a SOAP request
that I create manually in a StringBuffer.  I have been trying to put a key of
SOAPAction with an associated value in the hashtable which represents the
headers but so far have not had any success.

It appears SOAPAction is required according to one version of the SOAP spec i
read.  It appears that the Perl implementation of SOAP uses SOAPAction most of
the time whereas most Apache SOAP configs don't.  Has anyone successfully had
Apache SOAP talking to Perl SOAP?

My other question is in regards to the RPCRouter servlet...is everyone hacking
this servlet apart before they deploy it?  because as far as i can see if
deployed as it is distributed it would still answer to all of the list, deploy
and undeploy calls...so anyone with malicious intent could query your server
and then undeploy your services.  I noticed that xmethods doesn't respond to
the list command...is there a way to turn off answering these requests or are
people just removing the code?

cheers
chuck

Re: Two Questions:SOAPAction and RPCRouter security

[Tony Hong <th...@xmethods.net>]

chuck clark wrote:

> Has anyone used/written any services which require the SOAPAction to be in the
> header?
> Right now I've been using the HTTPUtil.Post utility to send off a SOAP request
> that I create manually in a StringBuffer.  I have been trying to put a key of
> SOAPAction with an associated value in the hashtable which represents the
> headers but so far have not had any success.
>
> It appears SOAPAction is required according to one version of the SOAP spec i
> read.  It appears that the Perl implementation of SOAP uses SOAPAction most of
> the time whereas most Apache SOAP configs don't.  Has anyone successfully had
> Apache SOAP talking to Perl SOAP?

The SOAP::Lite for Perl services at XMethods all require SOAPAction .  For our
particular SOAP::Lite services, to get them working with Apache clients,  you
need to set the SOAPAction value in the "call" method - otherwise, an exception
is generated.  Note that it isn't a hard requirement of SOAP::Lite that
SOAPAction be used, it's more  how we implemented the services.

By "PerlSOAP" I'm not sure if you are referring to SOAP::Lite
(http://www.geocities.com/paulclinger/soap.html) or Developmentor SOAP for Perl
(http://www.develop.com/soap) .    In general, SOAP::Lite for Perl and Apache
SOAP get along very well, both in client and server mode.  Developmentor's Perl
version is a bit less interoperable with Apache - for example, it uses the type
"xsd:int" while Apache uses "xsd:integer"; this causes exceptions whenever you
are trying to pass integer values.

>
> My other question is in regards to the RPCRouter servlet...is everyone hacking
> this servlet apart before they deploy it?  because as far as i can see if
> deployed as it is distributed it would still answer to all of the list, deploy
> and undeploy calls...so anyone with malicious intent could query your server
> and then undeploy your services.  I noticed that xmethods doesn't respond to
> the list command...is there a way to turn off answering these requests or are
> people just removing the code?
>

We did indeed disable the ability to execute the built-in deployment services
(such as list , deploy, etc) from the outside.  We did this by redefining the
value for SERVICE_MANAGER_SERVICE_NAME  in the
org.apache.soap.server.ServerConstants class.   By changing this value, not only
was the ServerManager updated but also our own ServerManagerClient class, so we
have access to our own mgmt services using this class. Attempts from the outside
to execute those management  functions using the "standard" Target Object URI
will then fail.

Tony
XMethods

Re: Two Questions:SOAPAction and RPCRouter security

[Tony Hong <th...@xmethods.net>]

chuck clark wrote:

> Has anyone used/written any services which require the SOAPAction to be in the
> header?
> Right now I've been using the HTTPUtil.Post utility to send off a SOAP request
> that I create manually in a StringBuffer.  I have been trying to put a key of
> SOAPAction with an associated value in the hashtable which represents the
> headers but so far have not had any success.
>
> It appears SOAPAction is required according to one version of the SOAP spec i
> read.  It appears that the Perl implementation of SOAP uses SOAPAction most of
> the time whereas most Apache SOAP configs don't.  Has anyone successfully had
> Apache SOAP talking to Perl SOAP?

The SOAP::Lite for Perl services at XMethods all require SOAPAction .  For our
particular SOAP::Lite services, to get them working with Apache clients,  you
need to set the SOAPAction value in the "call" method - otherwise, an exception
is generated.  Note that it isn't a hard requirement of SOAP::Lite that
SOAPAction be used, it's more  how we implemented the services.

By "PerlSOAP" I'm not sure if you are referring to SOAP::Lite
(http://www.geocities.com/paulclinger/soap.html) or Developmentor SOAP for Perl
(http://www.develop.com/soap) .    In general, SOAP::Lite for Perl and Apache
SOAP get along very well, both in client and server mode.  Developmentor's Perl
version is a bit less interoperable with Apache - for example, it uses the type
"xsd:int" while Apache uses "xsd:integer"; this causes exceptions whenever you
are trying to pass integer values.

>
> My other question is in regards to the RPCRouter servlet...is everyone hacking
> this servlet apart before they deploy it?  because as far as i can see if
> deployed as it is distributed it would still answer to all of the list, deploy
> and undeploy calls...so anyone with malicious intent could query your server
> and then undeploy your services.  I noticed that xmethods doesn't respond to
> the list command...is there a way to turn off answering these requests or are
> people just removing the code?
>

We did indeed disable the ability to execute the built-in deployment services
(such as list , deploy, etc) from the outside.  We did this by redefining the
value for SERVICE_MANAGER_SERVICE_NAME  in the
org.apache.soap.server.ServerConstants class.   By changing this value, not only
was the ServerManager updated but also our own ServerManagerClient class, so we
have access to our own mgmt services using this class. Attempts from the outside
to execute those management  functions using the "standard" Target Object URI
will then fail.

Tony
XMethods