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.
Related
I'm having an issue with a project I'm working on. I have a Vue client which does API calls to my backend which is written in .NET Core 3.1. Both these applications are deployed on diffent servers.
Now the problem is that my backend server does not allow me to do API calls straight from the browser. So I have to do some kind of 'redirect' on the client server to reach my API.
So for example:
If I call backend_server/api/values I get an error (Firewall).
I think I should make like a second API or something, but I'm not sure how to handle this issue.
Does anybody have any experience on this? Any help is welcome!
Kind regards
You can have multiple options here
Remove the firewall rule -
This will allow your API to get hit from browser. If firewall is not managed by you you can't do this
Add IP or Port exception rule in firewall -
Instead of deactivating the entire inbound rule on server, you can allow specific ports or IP on firewall. Again if you have control on firewall
Create Proxy API -
Another way is you can create a middleware API that forwards your request and acts as a proxy. This will suffice performance, resource, time and compromise security. I recommend not to do this, But it's easily possible in .NET Core
Specify CORS policy -
If your Vue.js and API originates from same origin (IP), You can configure CORS in server which will restrict access to API only from same origin. That means only www.google.com can access GoogleAPI, Likewise. This will protect the API from other origins
Tunnel via VPN -
If security is a concern, Use a VPN service to tunnel your API requests. This can't be possible for every client using your web service.
The best way is to open a specific rule on server for your application if possible. Writing a proxy in between will have lot of disadvantages although can be accomplished.
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'm looking for a way to expose my customer's WCF Services as REST Services (and create all the security stack to support claims / oauth authentication and authorization)
I'm working on 2 different approach to do so:
Create a new REST Service which will act as a proxy to
expose my WCF Service as REST Services (11 services / 130 web methods to
migrate...) and secure it using an IP STS / RS STS
Use a existing product like Apigee which will do all those job for me and even more feature than initially planned.
I'm trying to play with Apigee first, but I'm facing an issue while creating the API Proxy.
I've deployed a simple WCF Service (with only 2 methods) on a Windows Azure VM exposed in basicHttp (which works as expected - means I test it in a Console app successfully, even when the client app is located outside my Azure's VM -).
Problem comes when I follow the Apigee workflow to expose it as a REST Service. I try to fetch service's wsdl on Apigee portal and got following error:
Error: Cannot invoke method getOperation() on null object
Does someone know where the issue come from ? I don't have much information from Apigee portal.
I already validate my wsdl through http://www.wsdl-analyzer.com/ but everything looks fine...
Meantime, Amazone webservice works fine on Apigee and generate the REST Service so problem seems to come from my service's WSDL
This bug has been fixed and will be included in the next release (R24.4). If you still have any problems with the new release, please let us know.
I recently got a similar error in the most recent version of Apigee (Version 141029).
The error: "Fetch WSDL Error: Cannot invoke method startsWith() on null object".
The fix was to rename my local file from "somename.xml" to "somename.wsdl".
as you can see, I am relatively new on SO please don't kill me after posting this question :) I will do my best to describe the dilemma I am currently in.
I am creating something like a "Guardian Service" that is hosted on Windows Azure inside a Worker Role. This service has external ports, that can be accessed via HTTPS to allow clients to call it's service methods.
The WCF service is meant to call other services hosted in other Worker Roles that have only internal ports open, and which can be accessed only through the use of the Guardian Service. That's the main idea. Similar to a proxy or something.
I read already an excellent article from Jim O'Neil, what the caveats are when you try to access internal service points from within other WCF Services hosted in worker Roles:
His blog Troubleshooting Endpoints on a WCF Web Role
This is not the point for this question, and totally clear to me how to do that.
I have no idea at the moment, how I could do this, without implementing every contract from every single service I want to make accessible from within the Guardian Service to the outside world.
There must be a better way to decouple those things.
Any tips are appreciated.
Thank you.
I do not know the exact requirements for your project but I would say that what you are looking for is WCF Routing. I've used it in the past to redirect requests for different versions of Workflow instances.
The way it works is completely transparent to the client connecting to its endpoint. The router implementation must decide where to send the requests to, based on the request data (message headers and body).
In your case, if you are using SOAP and namespaces correctly, you might be able to base your decision on the message soap address and then send the request to the correct endpoint. You could also look at the Action property of the message.
Some links that might be useful:
http://msdn.microsoft.com/en-us/library/ee517423.aspx
http://www.codeproject.com/Articles/227699/RoutingService-on-Azure
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.