There's a way to pass in the SOAPContext object to the
target method. From the SOAPContext object, you can get
the HTTPServletRequest. From the request, you can get
the user associated with this request (via getRemoteUser()
method.

Here's a snippet of my provider that does this (this version
of provider only works with RPCRouter in SOAP 2.2, won't work
with SOAP 2.1)

public class myProvider extends RPCJavaProvider {

  public void invoke(SOAPContext reqContext, SOAPContext resContext)
                    throws SOAPException {

    HttpServletRequest req = (HttpServletRequest)
              reqContext.getProperty(Constants.BAG_HTTPSERVLETREQUEST);

    // perform authentication here, check userId & password

    // invoke the method on the target object
    try {
      Response resp = RPCRouter.invoke( dd, call, targetObject,
                                                 reqContext,
                                                 resContext );
      Envelope env = resp.buildEnvelope();
      StringWriter  sw = new StringWriter();
      env.marshall( sw, call.getSOAPMappingRegistry(), resContext );
      resContext.setRootPart( sw.toString(),
                              Constants.HEADERVAL_CONTENT_TYPE_UTF8);
    }
    catch( Exception e ) {
      if ( e instanceof SOAPException ) throw (SOAPException ) e ;
      throw new SOAPException( Constants.FAULT_CODE_SERVER, e.toString()
);
    }
  };

}

> -----Original Message-----
> From: Mark Richman [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 15, 2001 7:40 AM
> To: [EMAIL PROTECTED]
> Subject: Passing HTTP auth info to service impl
> 
> 
> My stumbling block at this point is how to pass the HTTP 
> authentication info down to the service object itself (the 
> target object). My pluggable provider grabs it from the HTTP 
> headers, but once it locates and invokes the service, the 
> info is lost. I don't know of any way to hand off a security 
> context to a web service :( I am trying to avoid making 
> username & password as parameters to every method on my web 
> service. Simply restricting access is not my goal, as the 
> user's identity is a critical part of my business logic.
> 
> - Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to