I have to consume 3 web services (Sharepoint/Alfresco/Documentum CMIS) via WCF with HTTP Basic auth.
With Sharepoint or Alfresco, first request goes without Authorization header, receives HTTP 401, gets auto-retried by WCF with header, everything's fine.
But with Documentum, I receive HTTP 500 and a SOAP Fault instead, so WCF never gets an opportunity to send the header and returns the exception as-is.
I can of course add the headers manually via HttpRequestMessageProperty, but this looks like an ugly hack to me. Is there anything that could be configured on the WCF side to send headers with the first request, or on Documentum side to return 401?
You could try fronting the Documentum service with another web server that behaves properly, and passing the requests through?
I implemented something similar using IIS to front Apache Tomcat in order to use Windows Auth, and used the isapi_redirect.dll filter to pass requests through. More information about that can be found here: http://tomcat.apache.org/connectors-doc/reference/iis.html
Don't know if something like that is an option for you, but it may provide an easier solution in code.
Related
I have a question about enabling cross-domain calls.
I have a WCF Rest service that is hosted in xyz domain. I am able to test these REST APIs from Advanced Rest Client, Postman and Fiddler. I also have a WPF application that actively calls these API which is hosted in a different domain (say abc domain) which works fine in getting responses.
However, when I created a new Angular web application and a Windows Service (deployed on abc domain), and tried calling the APIs from these two components, I am getting a 405 error.
Can someone explain:
How REST clients always are able to successfully establish a connection?
How does my WPF successfully connects to the WCF service even though
its on a different domain?
Why is my Windows Service/Web App not able to talk to WCF?
I assume that the issue here is caused by the preflight request. The browser issues this OPTIONS verb request to ask the server if the origin is allowed to call the API in a non-safe manner.
If your WCF REST service does not deal with this request, the WCF runtime will try to dispatch the request to your service implementation.
However, if the runtime does not find a method to call for this verb, it will return a 405 Method Not Allowed response.
I've dealt with this in the past by using an IOperationInvoker implementation, installed via an IOperationBehavior. This article describes a slightly different way of doing basically the same.
I have WCF RESTful services running on IIS6. (public exposed on internet)
example
http://{domain}:8000/todoService.svc/countPerLabel?uMID={uMID}&userID={userID}
I have setup APIGEE proxy API manager gateway to call the the WCF services.
http://{APIGEE}/v1/todo/countperlabel?uMID={uMID}&userID={userID}
Case A. When i call the APIGEE url for the first time it works - but when i make another call it delays for few seconds and response with timeout/service unavailable.
If i wait for about 10 minutes and calls the service again Case A occurs.
I am not able to understand - if i call my service url independently without APIgee everything works well.
I don't not want to give third party developer access to naked API url therefore like to secure it using either APIgee or WSO2.
Is it something to do with proxy issues where my IIS6 not able to respond back to request from proxy server?
Kindly suggest.
Thanks
It seems you are having multiple endpoints. First call goes to one endpoint and the second to another one. Why dont you try a third call as well. If it works and the fourth one fails, then my explanation is correct. If it is the case, one of your endpoints may be having firewall issues.
Here is what I would like to do.
1. Service hosted in WCF
2. Client calls asking for a payload of messages
3. Service returns payload of messages and waits for client to respond
3.A. Client returns 200 (OK) status or something confirming messages received.
3.B. Client returns bad error status stating to not delete the messages on server.
4. Depending on 3.A or 3.B Service will take appropriate action.
I would like to do this by doing something like extending IDispatcher and writing extension methods. VS creating another service and having the client call that service to signal which messages it received. Unless that's best practices.
Thanks in advanced.
If acting on HTTP status codes is a requirement then WCF is probably not what you want to use. WCF was created to be able to write transport independent code so the bindings could be changed purely through configuration; no code changes required. The HTTP request handling is buried so deeply into HTTP-based bindings that you're better off using something like the OpenRasta framework to implement your HTTP (REST) style service. It is a very HTTP request aware framework.
Otherwise, look at this wsDualHttpBinding intro to accomplish something similar through the application API level.
Now i have a public Wcf REST service A, and several internal wcf REST services B, each of internal services are identified by name. Is it possible to create a router/proxy in service A, and then, when the users request the interface of service A, it can redirect the request to the internal services based on name?
I tried using:
WebOperationContext.Current.OutgoingResponse.Location = targetInternalPath;
WebOperationContext.Current.OutgoingResponse.StatusCode = HttpStatusCode.Redirect; // or MovedPermanently
All works fine except the headers that we get on the client side, Here is the details from Fiddler:
Transport
Location: http://locahost:9856/internalAddress/getimage
Content-type: null (It should be "image/png")
Content-Length: 0
In other words, the client knows the exact internal address, the content-type and content-length is incorrect. All are not what i want. I have been struggling with this issue for days, anybody has any idea?
Best Regards.
Johnny
I'm confused. What you are seeing in fiddler is exactly what you are asking it to do. Your service A is returning a redirect response. The client is supposed to respond to that redirect by following the URI in the Location header.
If you truly want to hide the internal services then you need to make the service A work like a proxy. It needs to make the request to the internal services itself and then return the response it gets back.
Are you trying to hide the internal services for security reasons or is it just the clients don't know about those internal servers in advance?
The WCF RoutingService functionality can't be used because it only supports soap-based bindings. You could use the IIS 7 URL Rewrite Module as suggested here by Matthias in the MSDN forum answer. You could configure it to redirect the calls to the internal REST based services (an overview of its use at this link). I'm not sure it will help re-write the response header contents but it's worth a look.
This question related to this post
Authorization Header is missing in Http request using WCF.
Is there way to explicity add authorization header into Http Request when making WCF call?
I am putting the same answer for this questions too that I put in the another question Authorization Header is missing in Http request using WCF. Because they are related. Actually, I was wrong about this question. I did see different behaviour when running HTTP analyzer. While Http anaylzer running, my application crashed after receiving 401 response. When Http analyzer application closed, the above code worked as expected. Since code worked as expected, authorization header was added by WCF.