We have a webservice client implemented with Spring WS.
This is a snippet of the code:
<bean id="aClient" class="class.aClient">
<property name="messageFactory">
<bean class="org.springframework.ws.soap.axiom.AxiomSoapMessageFactory" />
</property>
<property name="messageSenders">
<list>
<ref bean="httpSender" />
</list>
The client call works fine for a random period of time: minutes, hours, even days, and suddenly the next error appears:
org.springframework.ws.client.WebServiceIOException: I/O error: Forbidden [403]
There is a basic user/password authentication and the client runs inside Weblogic.
I've tried changing the minimum thread pool number, setting preemptive authentication,
and the result is the same. Randomly the error appears.
When this happens, the server implementing the WS is working fine (tested with soapUI)
The call always works again when the application server restarts.
Any help on this will be greatly appreciated.
I can provide more code if needed.
Thank you
David
Related
I was unable to access the ActiveMQ web console in 5.16 version.
I opened the required ports in AWS security group and I checked which ports are configured for console and the broker URL, yet the browser said "Page Not Found" so I looked into the jetty.xml and noticed this line:
<bean id="jettyPort" class="org.apache.activemq.web.WebConsolePort" init-method="start">
<!-- the default port number for the web console -->
<property name="host" value="127.0.0.1"/>
<property name="port" value="8161"/>
</bean>
I changed the host to 0.0.0.0:
<bean id="jettyPort" class="org.apache.activemq.web.WebConsolePort" init-method="start">
<!-- the default port number for the web console -->
<property name="host" value="0.0.0.0"/>
<property name="port" value="8161"/>
</bean>
Now I am able to access the web console. However does this give any security risk?
There is always inherently more risk when exposing additional points of entry into a system (e.g. a management console).
The ActiveMQ web console is a powerful tool which can be used to delete messages, remove destinations, stop the broker, etc. If a user gains unauthorized access to the web console then they can make a real mess. If you expose the web console to external users then be sure to secure it according to the documentation.
I'm doing a stress test on an API deployed in wso2 integrator server with a high number of requests. Every stress test session. I always get the first response as fault response with an
error code 500 (internal server error)
And the remaining responses are fine.
I noticed that if the session is expired and if I want to send a request with this session id, above problem is produced.
I'm using wso2ei 6.5.0 as my server application version.
Can anyone help me please to avoid this message?
Try adding the following properties to the API sequence.
<property name="NO_KEEPALIVE" value="true" scope="axis2"/>
<property name="DISABLE_CHUNKING" value="true" scope="axis2"/>
This will make sure that connections are properly closed in-between the test sessions.
I am newbie to WSO2 ESB, so far everything is OK.
I started exploring fire and forgot feature, looks like this can be used as below to invoke async calls to end points.
<property name="CHANNEL_COD" value="999"/>
<property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/>
<property name="OUT_ONLY" value="true"/>
But when tested the API with above code, still ESB invoking the end point in syncronous. Tried this approach with call and send mediators.
Would anybody please help me is there any link I am missing here.
With ESB 4.8.1 :
If ClientApiNonBlocking property is not set, send mediator should be asynchronous.
Because of FORCE_SC_ACCEPTED, 202 http status code will be sended back at the end of IN mediation (ie : the message has been delivered to your endpoint, without waiting for the response)
If it takes several seconds to send the message to the endpoint, the caller will receive 202 status code AFTER that.
If you want this status code to be sent ASAP, you can use clone mediator and move send mediator inside clone's target
I am relatively new to SOAP web services, and it seems to be a basic thing, but still, I cannot find the way so solve it. I have a SOAP server written using Spring WS with XWS security. These are the relevant beans:
<bean id="wsSecurityInterceptor" class="org.springframework.ws.soap.security.xwss.XwsSecurityInterceptor">
<property name="policyConfiguration"
value="classpath:security-policy.xml"/>
<property name="callbackHandlers">
<list>
<ref bean="passwordValidationHandler"/>
</list>
</property>
</bean>
<bean id="passwordValidationHandler" class="org.springframework.ws.soap.security.xwss.callback.SimplePasswordValidationCallbackHandler">
<property name="users">
<props>
<prop key="user">*****</prop>
</props>
</property>
</bean>
And the following is security-policy.xml:
<xwss:SecurityConfiguration xmlns:xwss="http://java.sun.com/xml/ns/xwss/config">
<xwss:RequireUsernameToken passwordDigestRequired="true" nonceRequired="true"/>
<xwss:UsernameToken digestPassword="true" useNonce="true"/>
</xwss:SecurityConfiguration>
The thing is that I want to extablish a digest authentication using nonce (a one-time token that prevents an intercepted request from being sent again). As far as I know (and it is described here http://www.whitemesa.com/soapauth.html#S4), the server should create a challenge (nonce and timestamp, I think) and then the client should encrypt it with its password and timestamp and send it back to the server for verification. And this it should work for every request. Even if the user sends an empty request, the server should provide a challenge. But in my case it does not work. Am I missing something?
As it turned up, it is not necessarily the server who should generate nonce. I generated it on client, concatenated and hashed it according to the rules and then sent to the server. Frankly speaking, I could only find the root of error by debugging Spring WS sources and looking for where exactly an authentication problem is.
As near as I can tell, the WSO2 ESB does not properly handle proxying a service operation that does not return a response message.
Here's the scenario:
We've got a code-first, axis2 generated web service sitting on WSO2 application server 4.1.0.
The java class that the service is based on has some methods like:
public void updateMyObject(MyObject obj) throws MyServiceException
Axis2 generates a WSDL that does not contain a response message, so this is essentially one-way.
NB: An axis2 generated client stub operating against this operation works fine. When invoking the stub in client code, the client blocks until the operation is successfully processed by the server. If an error occurs on the server, then the custom fault is raised and an exception is thrown on the client side.
But, we want to make this invocation via the ESB. Setting up a simple, basic proxy server will not work. When invoking the service via the ESB, the client code blocks indefinitely even though the remote service was successfully invoked.
I read somewhere that this can be fixed by adding the following to my inSequence:
<property action="set" name="OUT_ONLY" value="true"/>
<property action="set" name="FORCE_SC_ACCEPTED" scope="axis2" value="true"/>
This does the trick in the case that the remote service successfully processes the response. The client code no longer blocks.
However, if there is an error processing the request, the client doesn't know. The ESB basically "eats" the error.
This is no doubt because there is no call-back handler registered for the operation because of the OUT_ONLY setting. Search for OUT_ONLY in the link below for more info:
http://techfeast-hiranya.blogspot.ca/2009/12/wso2-esb-tips-tricks-03-transport.html
The FORCE_SC_ACCEPTED setting seems to be the thing that will keep the client from blocking on the success condition, presumably because that forces a 202 http response to the client so it stops waiting for a response.
Since the client operates as it should against the service for both success and error conditions but I am unable to configure a proxy service that yields the same behavior, in my opinion, the ESB is deficient in this way and that is a bug.
Of course, if there is a way I can configure it so that it does what I want, then I'd love to hear it.
But as near as I can tell, I think not registering a call-back is the wrong thing to do here, even if there is no response. I do not wish to implement a fire and forget here. Executions should still happen synchronously from the client side. My client is expecting an HTTP 200 response but with no body for success.
By examining the WSDL, the ESB should realize that the service has no response message but still register a call back. When the 200 OK is received on success, it should propagate this back to the client and unregister the call-back. When a Fault occurs, it should also relay that back to the client.
So, is there a way to accomplish what I want with the ESB or is it deficient in this way?
However, if there is an error processing the request, the client doesn't know. The ESB basically "eats" the error
What is happening to your client if you define a fault sequence for your proxy in this case?
If we register a call-back fro an outonly operation, what will happen is ESB will wait forever for the response and will run out of threads..
In oneway message;
If it is a successcase use these two properties;
<property action="set" name="OUT_ONLY" value="true"/>
<property action="set" name="FORCE_SC_ACCEPTED" scope="axis2" value="true"/>
For a failure case handle that in the fault sequence. I would like to know, what is happens in the fault scenario.