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.
Related
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.
Given the free/open web-service for climate at:
http://eklima.no/wsKlima/standard/standard_en.html
with its web service interface at:
http://eklima.no/metdata/MetDataService
and WSDL at:
http://eklima.no/metdata/MetDataService?WSDL
I have been trying to use this as testcase for experimenting with mule web-proxy pattern configuration.
I have tried this config variant:
<pattern:web-service-proxy name="klimamet-ws-proxy"
inboundAddress="http://localhost:8080/klimamet"
outboundAddress="http://eklima.no/metdata/MetDataService" />
Now if i access the real web seb service directly, it will give me a proper response:
http://eklima.no/metdata/MetDataService?invoke=getMetData×erietypeID=0&format=&from=2006-01-01&to=2006-01-05&stations=18700&elements=tam&hours=&months=&username=
Then if i access the proxy just to get the wsdl, it works:
http://localhost:8080/klimamet?wsdl
but if I do a real service request towards the proxy:
http://localhost:8080/klimamet?invoke=getMetData×erietypeID=0&format=&from=2006-01-01&to=2006-01-05&stations=18700&elements=tam&hours=&months=&username=
then i just get the documentation page (same as: http://eklima.no/metdata/MetDataService), and not the expected soap xml-response.
I don't see any proper clue of what's wrong by looking in the logs.
By that way I have tried other variations of the config, but it just gives me other types of errors.
I will be thankful if anyone can help me spot the problem.
The Web Service proxy works with standard SOAP requests, i.e. HTTP POSTed SOAP envelopes. You are using HTTP GET here. Please use HTTP POST with the web-service-proxy.
If you really want to keep using GET, then switch to the pattern:http-proxy, which will forward the GET parameters to the outbound endpoint. Note that it will not rewrite the WSDL so clients of your proxy won't be able to rely on it.
I'm building a WCF router which needs to act as a proxy for a number of internal web services (WCF and ASMX). The routing part is fairly straight-forward, but I can't understand how the service metadata exchange would work in this solution.
In other words: how would a client obtain metadata for an internal service behind the router? Do I need to manually supply WSDL files to the consumer? Can I somehow setup the router to return the metadata for an appropriate internal service?
Or perhaps my architecture is completely wrong?
I see 2 options here:
It may be an option to create a "non-transparent" proxy, if you don't want to expose the internal addresses. The advantage is that you can do more than just routing messages (i.e. such proxy may serve as a "security boundary", unwrapping ciphered messages and passing them plain to the internal endpoint). It can also provide an "interoperable level", exposing a WCF service as simple SOAP using same datatypes/message XML structure. The downside is that you'll have to update its code along with the proxied services
You may implement a WSDL rewriter. With it, you can mask the internal service URL on-the-fly - depending on your conditions, a simple string replace may or may not suffice.
Refer to:
Message Inspectors
IWsdlExportExtension
The same "router service" can also be used to get the individual WSDL for internal services behind the router.
Check out this thread
Have you considered using a simple HTTP Proxy instead? All WCF using REST or SOAP are at their core HTTP requests. It seems like the routing functionality (which I am assuming you are basing on hostname, URL path or parameters) could be performed by proxying the HTTP request without needing to understand the contents. ASP.Net will do a fairly good job of sanitizing incoming requests on its own, but you could always add additional custom filtering as necessary.
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.
I am trying to write a WCF service as a proxy for my Silverlight control to do cross-domain requests to an internet REST web service. I just want to make the requests to my service, and it would format and forward the request to the 3rd party web service (replace the hostname and part of the URL), then simply return the response to the caller.
Is my approach correct? The 3rd party server does not have the crossdomain.xml file to allow my call otherwise.
My question is, given my WCF service approach, I would like to rewrite the response body in my service with the response body I retrieved from the 3rd party service, and if possible, rewrite the response header to also be the one I got from that service. This way it minimizes the translation that my web service has to do on the response. Is it possible for me to do this rewrite? if so, how? if not, what are the best practices to implement this?
My interface is right now very primitive, something like this, simply because i don't need anything more than this. The response from the 3rd party service is a JSON response.
[ServiceContract]
interface IMyProxy
{
[OperationContract]
[WebGet(UriTemplate = "relay/{requestOptions}")]
string ForwardRequest(string requestOptions);
}
p.s. I do not need it to work with HTTPS, so no need to worry about the man-in-the-middle issue.
I figured it out, I believe (WebOperationContext).
I am still having an issue that if I duplicate the "Transfer-encoding" of the 3rd part service in my reply, I get an obscure exception down from the guts of the framework (something is "NotFound")... but that's a different story.