Hi,
I doesn't find any shortcut (a Property in SOAPContext), so it should be
done by hand:
- get the rootPart from SOAPContext
- make an InputSource from the rootPart like in
org.apache.soap.transport.TransportMessage.getEnvelope()
- Parse this with a XML-Parser
- call Envelope.unmarshall(...) with the root-Element as param
- access the Header of the envelope
That's only a guess and the developers may have a better solution,
because this is all done in the RPCRouterServlet. But I haven't found a
place where the Envelope is stored in the SOAPContext.
I send a general suggestion for handling security and access to a
deployed service to the dev-list today.
May be your problem is the same. I add the message here, because it
describes a general solution for the access handling to a service.
Bernd
+++ previously sent to soap-dev:
I have a security problem with apache-soap. To solve it, it would be
nice, if the Provider-class for the ServiceManager-methods(SMM) (deploy,
undeploy and list) could be configured by the saopconfig file
(soap.xml).
The reason follows:
If someone is allowed to access one service, he can access all services
witch are deployed on the server, espacially the deploy, undeploy and
list methods of the ServiceManager. I saw in the latest cvs version
(HEAD) that the deployment of the ServiceManager-methods could be
switched off, but this is a all or nothing solution. The only way to
deploy a service, after switching it off, is to use the JSPs and make it
secure with SSL and login via tomcat.[...]
But there is still the routing problem. I want to fix it with my own
Provider-class. This could check via the locate-function if the request
for this IP, server-name, port etc. is allowed with/without a login. The
login could happen as a SOAP-Header or HTTP-Auth. But the Provider for
the SMM is hardcoded, so making that configurable could solve the
security problem for these methods. Than we could use the
ServiceManagerClient with an untouched uri on a special Port with SSL
and Client-Auth. With one new config-option the rest can be untouched
and every developer could control the access to all deployed services,
without building it in the deployed service classes, with the
SOAPContext.
I hope I don't miss something and this feature is useful. If there are
interests in this, I could write the provider and give it to
apache-soap.
+++++
--
Dipl.-Inform. Bernd Koecke
UNIX-Entwicklung
Schlund+Partner AG
Fon: +49-721-91374-0
E-Mail: [EMAIL PROTECTED]
