How do I set custom HTTP headers on an ESB proxy service Out Sequence? I'm trying to set "Access-Control-Allow-Origin" to allow my javascript/html front-end page to be able to GET the XML that is provided by this service. I also need to add a Cache-Control.
If there is a way to do this directly on my WSO2 Data Services Server (DSS), that would be preferable as it would avoid adding an ESB server to my process. According to this forum post from about a year ago, it's not possible: http://wso2.org/forum/thread/13991
I've tried it several ways, but looking at fiddler, the header is unchanged:
HTTP/1.1 200 OK
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 637
Date: Wed, 28 Mar 2012 20:58:31 GMT
Server: WSO2 Carbon Server
I'm somewhat new with WSO2 servers (more of a front-end dev), so the answer could be right in front of me.
You can do this by adding a Property mediator to the out-sequence. Once you set the property with the transport scope there, it will be added to the transport header of the out going message from the ESB.
This property mediator worked for me:
<property name="Access-Control-Allow-Origin" value="*" scope="transport" type="STRING"></property>
It allows access from any origin.
-Kari
Related
I tried to publish a message to both the default exchange and also some other exchange via the HTTP Management API but I always get back an authorization error.
curl -i -u myuser:mypw -XPOST -d'{"properties":{},"routing_key":"my_key","payload":"my body","payload_encoding":"string"}' https://myinstance.rmq.cloudamqp.com/api/exchanges/vhost/myvhost/publish
HTTP/1.1 401 Unauthorized
Server: nginx/1.14.2
Date: Mon, 01 Apr 2019 05:27:10 GMT
Content-Type: application/json
Content-Length: 53
Connection: keep-alive
content-security-policy: default-src 'self'
vary: accept, accept-encoding, origin
{"error":"not_authorised","reason":"Access refused."}%
I tried it both on a self hosted RabbitMQ (installed via helm on k8s) and our CloudAMQP instance.
But if I login on the Management Web UI with the very same user then I can publish a message to the exchange and also consume from a queue.
I expect that the Management Web UI just uses the HTTP API for performing this actions so I am confused why it works when I do it via the UI.
Reading all vhost on the other hand works also with the HTTP API.
curl -i -u myuser:mypw https://myinstance.rmq.cloudamqp.com/api/vhosts
HTTP/1.1 200 OK
Can somebody explain to me whats going on there? What puzzels me the most is the fact that it works on the UI using the same user:pw.
I figured out the problem, I did use the wrong URL path.
For vhost: / and the default exchange it should be:
http://myinstance.rmq.cloudamqp.com/api/exchanges/%2F/amq.default/publish
In my case, using the CloudAmqp free plan, I needed to use my user name as vHost in rhe URL:
https://myinstance.rmq.cloudamqp.com/api/exchanges/[myrandomusernamefromfreeplan]/amq.default/publish
When I send a http request to my couchdb server like it is shown in the docs here CouchDB Proxy Authentication, it doesn't give the response shown in the docs, just empty data. What am I doing wrong?
Also, am I able to start a session with this Proxy Auth? If I try a POST /_session, I get 500 error code.
GET /_session HTTP/1.1
Host: 127.0.0.2:5984
User-Agent: curl/7.51.0
Accept: application/json
Content-Type: application/json; charset=utf-8
X-Auth-CouchDB-UserName: john
X-Auth-CouchDB-Roles: blogger
< HTTP/1.1 200 OK
< Cache-Control: must-revalidate
< Content-Length: 132
< Content-Type: application/json
< Date: Sun, 06 Nov 2016 01:10:58 GMT
< Server: CouchDB/2.0.0 (Erlang OTP/17)
<
{"ok":true,"userCtx":{"name":null,"roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["cookie","default"]}}
I found in the CouchDB issue tracker that the Proxy Authentication is broken in version 2.0.0. Either that or the docs aren't updated to indicate that it only works with clusters or something. I changed back to version 1.6.1 and everything works fine. I must say that the documentation for how Proxy Authentication works is very poor.
How it works is you need your third party authentication server to have the "[couch_httpd_auth] secret" and when a client authenticates, you need to generate a HMAC-SHA1 token by combining the username and secret. Then, on any http requests you make from the client to the CouchDB server, if you include all the headers:
X-Auth-CouchDB-Roles
X-Auth-CouchDB-UserName
X-Auth-CouchDB-Token
that request will be authenticated as a user client.
Also, it is not mentioned in the docs, but POST on the /_session API using these headers does nothing.
It's not the Proxy Authentication itself which is broken in CouchDB 2.0, it's just that in the current release there's no way to configure the authentication handlers like there was in the old 1.6 days.
There are some patches mentioned in the issue tracker which add proxy authentication to the list of authentication handlers. Furthermore there was a pull request which was accepted and merged which brings back configurability to CouchDB 2.0.
However in order to take advantage of those I'm afraid you either have to wait until the next release, or build CouchDB 2.0 yourself from the sources.
Proxy authentication is fixed as of CouchDB 2.1.1. The latest (>2.1.1) documentation shows how to configure proxy authentication again, along with the important proxy_use_secret option.
I configured my WCF service to https. I can browse WSDL using my https:// url address. However, when I test the service using SOAP UI, the URL deafults to http. I do receive expected response when I test it. If I change the URL in SOAP UI to https, I get the following.
HTTP/1.1 404 Not Found
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Tue, 04 Dec 2012 16:46:32 GMT
Content-Length: 0
This question is related to my other question:
Why my WSDL still shows basic http binding with the location value of http?
Any ideas?? Is this a problem with IIS configuration?
I'm not sure if this is your (only) problem since you haven't posted your configuration, but you need HttpsGetEnabled set to true and also need to use an https base address.
http://msdn.microsoft.com/en-us/library/ms751498.aspx
Finally, I was able to fix it by changing wsHttpBinding to basicHttpBinding. Everything works now.
When I try to access WCF client, I get the following error. I was able to access my service using IE and able to reference in VS 2010. My development environment is Windows server 2008. I hosted service in Sharepoint Project server. I am stuck with this error. Please advice.
"The content type text/html; charset=UTF-8 of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. "
Here is some data Headers from Fiddler.
GET /_vti_bin/psi/helloservice.svc HTTP/1.1
Content-Type: text/xml; charset=utf-8
MicrosoftSharePointTeamServices: 14.0.0.4762
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
X-SharePointHealthScore: 4
WCF HTTP Activation must be enabled on the server. If the script maps for WCF are not installed you may receive the error.
I am trying to post data from InfoPath using the WebServiceConnection, to a WFC service inside of AppFabric.
The messgae never arrives in AppFabric, and I think I know why.
My WCF service is configured like this
<endpoint address="Workflow1.xamlx" binding="basicHttpBinding" contract="WorkflowOperation" />
And when it is called by WCF Test Client, it generates the header
<s:Header>
<a:Action s:mustUnderstand="1">http://tempuri.org/WorkflowOperation/ReceiveFormPayload</a:Action>
</s:Header>
However, InfoPath does not generate this Soap header, it only generates the HTTP header
POST /Workflow1.xamlx HTTP/1.1
SOAPAction: "http://tempuri.org/WorkflowOperation/ReceiveFormPayload"
Content-Type: text/xml; charset="UTF-8"
User-Agent: SOAP Toolkit 3.0
Host: localhost:51842
Content-Length: 1893
Connection: Keep-Alive
Cache-Control: no-cache
How do I configure my WCF endpoint to only need the HTTP-header action, and not the Soap Action?
Well, I'm back again, with the answer for anyone who is interested in getting InfoPath to submit data to an AppFabric service.
The .NET BasicHttpBinding uses a combination of Soap1.2+WSAddressing1.0 - while the InfoPath client will ONLY submit to web services using Soap1.1 (with NO WSAddressing support) - rending the two completely incompatible.
I actually ended up having to write an intermediary broker which would adapt the invocations.
Many thanks to "codemeit" for a very descriptive page of the composition of the various WCF binding types.