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.
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.
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
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.
Context:
BizTalk 2010 trying to call a one way(fire and forget) PeopleSoft service that does not return a response. I have verified that BizTalk 2010 does not support one way services by design. Unable to call one way Peoplesoft service with WCF-Adapter from BizTalk 2010
PeopleSoft team showed me that their asynchronous service returns the following Http status and headers.
HTTP/1.1 200 OK
Date: Thu, 20 Jan 2011 15:31:37 GMT
Content-Length: 0
Content-Type: text/xml; charset=UTF-8
TransactionID: <some GUID>
X-Powered-By: Servlet/2.5 JSP/2.1
However, when I look at the xml returned from a One Way WCF service published by BizTalk 2010 I see this
HTTP/1.1 200 OK
Content-Length: 86
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 20 Jan 2011 15:34:32 GMT
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body/></s:Envelope>
Note the empty SOAP message.
Therefore, BizTalk 2010 needs to have a NON-NULL response to be able to call a service.
PeopleSoft service sending back the HTTP status code above IS NOT considered an acknowledgement by BizTalk.
Is that correct?
Thanks.
If a web service does not return a response, it needs to return an HTTP 204 - No Content. I've not tried this in WCF yet, but HTTP honors the no content return code. As for the BizTalk WCF service... not sure why it's not using 204. But since it is using 200, it needs to send something.
It looks like BizTalk 2010 does need to have a NON-NULL response to be able to call a service.
Thanks to Ben for confirmation.
See details here.
What is the nature of the message you send out? You could in theory send a one way HTTP message and correlate on a separate HTTP response port.