Add authorization from REST client to http request in mule - http

We have the authorization header sent from a REST client and this can be seen in the inbound properties after the HTTP listener connector at the start of the mule flow in 3.7.
We call an API in the same flow using a http request configurator and want to send the same authorization header in the call.
We have added it as a header in the parameter section in the http request configurator but it fails. How do we do this?

You can directly copy the Authorization property using the copy-properties message processor, something like below:
<http:listener config-ref="HTTP_Listener_Configuration" path="/" allowedMethods="GET" doc:name="HTTP"/>
<copy-properties propertyName="Authorization" doc:name="Property" />
<http:request config-ref="HTTP_Request" path="/test" method="GET" doc:name="HTTP"/>

I think you need to use a Message Property component and set your authorization in an Outbound Property before calling your HTTP:
Your Property will be:
I hope this can help you.

Related

Mule calling rest api fails with " Response code 404 mapped as failure. "

I am trying to consume a rest api via mulesoft but from postman when i invoke the mule endpoint it gives the following error "Response code 404 mapped as failure."
<http:request-config name="HTTP_Request_Configuration" host="xxxxx" port="80" doc:name="HTTP Request Configuration" basePath="/xxx/Members"/>
<http:request config-ref="HTTP_Request_Configuration" path="/{mID}/Members" method="GET" doc:name="HTTP">
<http:request-builder>
<http:uri-param paramName="mID" value="#[flowVars.memID]"/>
</http:request-builder>
</http:request>
The error message you are getting in Mule indicates that the REST API you are calling from Mule is returning a 404. This means that you are requesting a resource that doesn't exist.
Check your config and the service you are consuming to make sure they match. From your code above the URL that Mule will be requesting is:
http://xxxxx:80/xxx/Members/{mID}/Members
This is built up from the host, port and base path of the HTTP config along with the path of the HTTP Request component.
Not having any knowledge of the API you are trying to consume I can't tell you what it should be in your specific case. If you have documentation that describes the service you should be able to adjust your mule configuration to match it.
Hope that helps.
Johnson.

Mediation sequence for DELETE method in wso2 not working

I have a SOAP web service for delete action, with endpoint URL
http://some-ip-address:my-port/bank/websrv/delcus
And can be invoked only by POST method.
I have published this API and added DELETE resource for invoking this service.
So the URL becomes
https://my-apim-endpoint/public/customer/{customer-id}
And I added mediation sequence for DELETE action. So whenever this API is invoked, it will go through the mediation sequence and send POST request to the endpoint
http://some-ip-address:my-port/bank/websrv/delcus
But when I invoke the API, the endpoint URL is getting replaced with the following URL.
Here is how the send mediator looks like,
<send>
<endpoint>
<http method="post" uri-template="http://some-ip-address:my-port/bank/websrv/delcus"/>
</endpoint>
</send>
http://some-ip-address:my-port/bank/websrv/100000023
Instead of
http://some-ip-address:my-port/bank/websrv/delcus
And giving me error response. Please anyone can help?
When you use http type endpoint, the resource path get appended to the endpoint url. for example say you have an endpoint http://test.com/path and if you have defined a /resource/{id} resource, then the request will be sent to http://test.com/path/resource/{id} kind of a url. That is the default behavior.
To call a SOAP service instead of using http type endpoint, you can use use address endpoint type. when you create endpoint with address type, you can define whether it is a soap11 or soap12. (format option in advanced options section in the implement tab). this will send a soap payload to http://test.com/path. (you do not have to build soap headers etc. only message body) .

CORS error - No 'Access-Control-Allow-Origin' header is present on the requested resource

I am using an Angular front end to connect to a WEB API 2 backend. The failing use case is the following. When a user registers, on successful registration, they must be logged into the system and be redirected to a new page to collect further information. I am using TOKENS for authentication.
I have enabled CORS in the WebAPI config:
var cors = new EnableCorsAttribute("http://localhost:7812", "*", "*");
config.EnableCors(cors);
The registration request is successful and the response headers have the required CORS headers:
**Access-Control-Allow-Credentials:true
Access-Control-Allow-Origin:http://localhost:7812**
Content-Length:0
Date:Sun, 24 Aug 2014 09:31:55 GMT
Server:Microsoft-IIS/8.0
X-Powered-By:ASP.NET
X-SourceFiles:=?UTF-8?B?QzpcUHJvamVjdHNcVGVzdGluZ1xNYWx0QXBhcnRtZW50c1xNYWx0YXBhcnRtZW50cy5BUElcTWFsdGFwYXJ0bWVudHMuQVBJXGFwaVxhY2NvdW50XHJlZ2lzdGVy?=
In the next step I attempt to log in the user to the system. As part of the login, the front end requests a TOKEN from the server at Request URL:http://localhost:7802/token. The request header once again sends a Origin header Origin:http://localhost:7812 but this time I get the error : XMLHttpRequest cannot load http://localhost:7802/token. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:7812' is therefore not allowed access.
Anyone have any ideas?
When dealing with CORS, we need to keep in mind that there may be two requests sent by the browsers for a non GET request. There is usually the preflight (OPTIONS) request and then the actual request (POST). During the preflight requests, the server needs to add the Access-Control-Allow-Origin header with the value matching the request Origin header. This authorizes the subsequent request to be sent.
For the subsequent/actual request, the server also needs to add the Access-Control-Allow-Origin header. Otherwise, this request fails.
When using the OWIN OAuthAuthorizationServerProvider, we need to customize the MatchEndpoint handler to manage the header logic. This handler is executed before validate client authentication.
For more background information, look at this link: http://www.ozkary.com/2016/04/web-api-owin-cors-handling-no-access.html
It's because of Preflighted requests.
Read these articles for solutions:
How to make CORS Authentication in WebAPI 2?
http://www.codeproject.com/Articles/617892/Using-CORS-in-ASP-NET-WebAPI-Without-Being-a-Rocke
I believe you got two problems :
1- With Web API 2, you need to add the header manually when you grant the bearer token.
2- Your data needs to be url encoded, so you need to intercept the $http post message to encode the data.
refer to my article which I use Web API 2 from an AngularJS client side.
http://www.codeproject.com/Articles/742532/Using-Web-API-Individual-User-Account-plus-CORS-En
Hope that helps.
Use these line in web.config :
<system.webServer>
<modules>
<remove name="WebDAVModule" />
...
</modules>
<handlers>
<remove name="WebDAV" />
...
</handlers>
</system.webServer>
Its fixes my problem, may be it also help you.

Default HTTP method for outbound endpoint in MULE ESB

What is the default HTTP method that an outbound endpoint in MULE uses? For example, if I have the following endpoint:
<https:outbound-endpoint exchange-pattern="request-response"
address="https://api.example.com/makeCall">
Will the message be sent with a GET or POST?
Since the method property of an HTTP/HTTPS outbound endpoint is not required, there is no default property set by Mule - according to the Mule documentation.
However, this blog post suggests that the default method for an outbound endpoint, like the one in your example, is POST. Since this blog post isn't official, I can't guarantee it's reliability. Hope this helps!

Prevent Mule from adding default content type

How do I prevent Mule from adding a default content-type to HTTP responses?
Currently, Mule is adding 'text/plain' content-type. I have REST calls that don't always specify the expected content, and services that don't indicate the served content - leaving it to the client (browser) to interpret.
My "proxy" flow looks like this:
<flow name="DragonScalaProxy" doc:name="DragonScalaProxy">
<http:inbound-endpoint address="http://localhost:8002" exchange-pattern="request-response" doc:name="HTTP" disableTransportTransformer="true"/>
<logger level="INFO" doc:name="Logger"/>
<copy-properties propertyName="http.method" doc:name="Copy HTTP Method"/>
<message-properties-transformer doc:name="Message Properties">
<delete-message-property key="Content-Type"/>
</message-properties-transformer>
<http:outbound-endpoint address="http://localhost:8000#[header:INBOUND:http.request]" exchange-pattern="request-response" doc:name="HTTP" disableTransportTransformer="true"/>
<remove-property propertyName="Content-Type" doc:name="Remove Content-Type"/>
<message-properties-transformer doc:name="Message Properties">
<delete-message-property key="Content-Type"/>
</message-properties-transformer>
<logger level="INFO" doc:name="Logger"/>
You can use a transformer to set it to whatever you want.
Eg like so for a xml type:
<message-properties-transformer name="contentTypeTextXML">
<add-message-property key="Content-Type" value="text/xml" />
</message-properties-transformer>
or you can delete it with the delete-message-property processor
I had a similar problem; whenever I would transform the payload of a Mule message to be JSON, the Mule runtime would automatically set the MIME type of the Mule message to be application/json. When the http:request component saw a MIME type of application/json, it would then set the content-type of the HTTP request to be application/json, as well. Unfortunately, the RESTful service that I needed to call only recognized a content-type of text/x-json. While the MIME type of the Mule message was set to application/json, I was unable to manually override the content-type used by http:request; it simply ignored the http:header setting for content-type. I solved this dilemma by adding an expression-component to override the MIME type set within the Mule message's SimpleDataType, and then I was finally able to successfully override the content-type within the http:request component to be the type that I needed, like so:
...
<expression-component doc:name="Override default DataType"><!CDATA[
message.getDataType().setMimeType('*/*');
]]></expression-component>
<http:request config-ref="HTTP_Request_Configuration" path="search.do" method="POST" doc:name="Call RESTful service to perform search">
<http:request-builder>
...
<http:header headerName="content-type" value="text/x-json"/>
...
</http:request-builder>
</http:request>
...

Resources