[JBossWS] - Re: Dispatch WS-Security Bug
by cavani
Further exploration and minimal code change seems to fix this issue:
First, changing direction (pivotation) from out- to in-bound.
| (...)
| resMsg = getRemotingConnection().invoke(reqMsg, epInfo, false);
|
| msgContext = MessageContextJAXWS.processPivot(msgContext);
| msgContext.setMessageAbstraction(resMsg);
|
| // Call the response handler chain, removing the fault type entry will not call handleFault for that chain
| handlerPass = callResponseHandlerChain(portName, handlerType[2]);
| (...)
|
With this, WS-Security Handler is called to decrypt the response message, but it result in an NPE.
In class WSSecurityDispatcher, method handleInbound, I change string definition with null test.
| (...)
| OperationMetaData opMetaData = ctx.getOperationMetaData();
| if (opMetaData == null)
| {
| // Get the operation meta data from the soap message
| // for the server side inbound message.
| EndpointMetaData epMetaData = ctx.getEndpointMetaData();
| opMetaData = soapMessage.getOperationMetaData(epMetaData);
| }
|
| String operation = opMetaData == null ? null : opMetaData.getQName().toString();
| String port = opMetaData == null ? null : opMetaData.getEndpointMetaData().getPortName().getLocalPart();
|
| List<OperationDescription<RequireOperation>> operations = buildRequireOperations(config, operation, port);
| (...)
|
It is working now, but I don't have sure if this is all, but it is almost good (I really like upstream fix).
Thanks,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122863#4122863
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122863
18 years, 2 months
[JBossWS] - Accessing USERNAME_PROPERTY from Web Service class
by mjhammel
In my client I do this to authenticate with BASIC authentication:
/* Setup to authenticate with the server. */
| bp.getRequestContext().put(BindingProvider.USERNAME_PROPERTY, subscriberID);
| bp.getRequestContext().put(BindingProvider.PASSWORD_PROPERTY, pw);
|
I'd like to access the USERNAME_PROPERTY from within my web services class. With JBOSS 4.0.5GA and Axis 1.1 (I think) I did this:
final MessageContext msgContext = MessageContext.getCurrentContext();
| msgContext.getUsername();
|
With JBOSS WS 2.0.2 GA (running under JBOSS 4.2.2GA) I've dropped Axis and so I've tried things like this, but none seem to work:
| @Resource
| WebServiceContext wsContext;
|
| ...
|
| MessageContext msgContext = wsContext.getMessageContext();
| String username = (String) msgContext.get(BindingProvider.USERNAME_PROPERTY) ;
|
What's the correct way to access this message property from the server side?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122860#4122860
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122860
18 years, 2 months
[JBossWS] - Dispatch WS-Security Bug
by cavani
I was trying to use WS-Security with JAX-WS Dispatch from version 2.0.2 but the response message returned still encrypted (it works with generated client). After some debug and code reading, I think that I figured it out.
On DispatchImpl, the code is:
| (...) msgContext.put(MessageContextJAXWS.MESSAGE_OUTBOUND_PROPERTY, Boolean.TRUE);
|
| QName portName = epMetaData.getPortName();
| try
| {
| // Call the request handlers
| boolean handlerPass = callRequestHandlerChain(portName, handlerType[0]);
| handlerPass = handlerPass && callRequestHandlerChain(portName, handlerType[1]);
| handlerPass = handlerPass && callRequestHandlerChain(portName, handlerType[2]);
|
| // Handlers might have replaced the message
| reqMsg = (SOAPMessageImpl)msgContext.getSOAPMessage();
|
| MessageAbstraction resMsg = null;
| if (handlerPass)
| {
| Map<String, Object> callProps = new HashMap<String, Object>(getRequestContext());
| EndpointInfo epInfo = new EndpointInfo(epMetaData, targetAddress, callProps);
| resMsg = getRemotingConnection().invoke(reqMsg, epInfo, false);
|
| // Call the response handler chain, removing the fault type entry will not call handleFault for that chain
| handlerPass = callResponseHandlerChain(portName, handlerType[2]);
| faultType[2] = null;
| handlerPass = handlerPass && callResponseHandlerChain(portName, handlerType[1]);
| faultType[1] = null;
| handlerPass = handlerPass && callResponseHandlerChain(portName, handlerType[0]);
| faultType[0] = null;
| }
| (...)
|
But on CommonClient / ClientImpl, the similar code block is a bit different, but, essentially, the direction change after invocation.
| (...)
| DirectionHolder direction = new DirectionHolder(Direction.OutBound);
|
| // Get the order of pre/post handlerchains
| HandlerType[] handlerType = new HandlerType[] { HandlerType.PRE, HandlerType.ENDPOINT, HandlerType.POST };
| HandlerType[] faultType = new HandlerType[] { HandlerType.PRE, HandlerType.ENDPOINT, HandlerType.POST };
|
| QName portName = epMetaData.getPortName();
| try
| {
| // Get the binding from the provider
| CommonBinding binding = (CommonBinding)getCommonBindingProvider().getCommonBinding();
| binding.setHeaderSource(this);
|
| // Create the invocation and sync the input parameters
| epInv = new EndpointInvocation(opMetaData);
| epInv.initInputParams(inputParams);
|
| // Set the required outbound properties
| setOutboundContextProperties();
|
| // Bind the request message
| MessageAbstraction reqMessage = binding.bindRequestMessage(opMetaData, epInv, unboundHeaders);
|
| // Add possible attachment parts
| addAttachmentParts(reqMessage);
|
| // Call the request handlers
| boolean handlerPass = callRequestHandlerChain(portName, handlerType[0]);
| handlerPass = handlerPass && callRequestHandlerChain(portName, handlerType[1]);
| handlerPass = handlerPass && callRequestHandlerChain(portName, handlerType[2]);
|
| // Handlers might have replaced the message
| reqMessage = msgContext.getMessageAbstraction();
|
| if (handlerPass)
| {
| String targetAddress = getTargetEndpointAddress();
|
| // Fall back to wsa:To
| AddressingProperties addrProps = (AddressingProperties)msgContext.get(JAXWSAConstants.CLIENT_ADDRESSING_PROPERTIES_OUTBOUND);
| if (targetAddress == null && addrProps != null && addrProps.getTo() != null)
| {
| AddressingConstantsImpl ADDR = new AddressingConstantsImpl();
| String wsaTo = addrProps.getTo().getURI().toString();
| if (wsaTo.equals(ADDR.getAnonymousURI()) == false)
| {
| try
| {
| URL wsaToURL = new URL(wsaTo);
| log.debug("Sending request to addressing destination: " + wsaToURL);
| targetAddress = wsaToURL.toExternalForm();
| }
| catch (MalformedURLException ex)
| {
| log.debug("Not a valid URL: " + wsaTo);
| }
| }
| }
|
| // The endpoint address must be known beyond this point
| if (targetAddress == null)
| throw new WSException("Target endpoint address not set");
|
| Map<String, Object> callProps = new HashMap<String, Object>(getRequestContext());
| EndpointInfo epInfo = new EndpointInfo(epMetaData, targetAddress, callProps);
| if (shouldMaintainSession())
| addSessionInfo(reqMessage, callProps);
|
| SOAPRemotingConnection remotingConnection = new SOAPRemotingConnection();
| MessageAbstraction resMessage = remotingConnection.invoke(reqMessage, epInfo, oneway);
|
| if (shouldMaintainSession())
| saveSessionInfo(callProps, getRequestContext());
|
| // At pivot the message context might be replaced
| msgContext = processPivotInternal(msgContext, direction);
|
| // Copy the remoting meta data
| msgContext.put(CommonMessageContext.REMOTING_METADATA, callProps);
|
| // Associate response message with message context
| msgContext.setMessageAbstraction(resMessage);
| }
|
| setInboundContextProperties();
|
| // Get the return object
| Object retObj = null;
| if (oneway == false && handlerPass)
| {
| // Verify
| if (binding instanceof CommonSOAPBinding)
| ((CommonSOAPBinding)binding).checkMustUnderstand(opMetaData);
|
| // Call the response handler chain, removing the fault type entry will not call handleFault for that chain
| handlerPass = callResponseHandlerChain(portName, handlerType[2]);
| faultType[2] = null;
| (...)
|
This is a bug, right? (sorry if I am wrong)
If so, this can be fixed fro 2.0.3 still?
Thanks,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122793#4122793
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122793
18 years, 2 months