HttpClient runs in local but stuck in AWS Windows Server - c#

I'm makin an API with net core 2.1 and run into a issue where I CAN gen a correct response in my local machine (even running the published files) BUT gen stuck when i upload and run the app in a aws ec2 windows server 2012.
I've tried using the IHttpClientFactory, adding the httpclient at services collection, making a service whith the AddHttpClient and running the release profile in my pc and with every method it runs fine in my pc but hangs in aws ec2 windows server 2012.
I'm running the app in aws ec2 with $netcore ./application.dll for now.
my pc has netcore 2.2.300 and aws 2.2.400
Here is the part of the code I use in my controller (also try with making a service):
WebCuitRequest req = new WebCuitRequest {cuit = "cuit", token = "Yt25zBH" };
string json = JsonConvert.SerializeObject(req);
string baseUrl = "url.com/getthis";
StringContent queryString = new StringContent(json, Encoding.UTF8, "application/json");
HttpResponseMessage res = await _client.PostAsync(baseUrl, queryString);
//------i dont get here (no error, no response)
HttpContent content = res.Content;
string data = await content.ReadAsStringAsync();
return data;
I expect an error or response but none is returned (i have a try/catch and some Console.write that never get reached).
Update 1 (solution):
Moving the API I was trying to reach to a hosting without cloudfare solved the problem. It seems that cloudfare was blocking the aws instance (but no my pc) and for some reason I didn't get a response or error. I must clarify that I have access to the target API and the posibility to move it, I don't know what can be done if you can't do changes in that env.
Tanks to Robert Perry who get me to evaluate another part on the situation.

This is most likely caused by Azures' default security settings. I believe it locks out calls to external IP addresses by default - its worth checking this article and matching it to how your Azure is configured: https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security

Moving the API I was trying to reach to a hosting without cloudfare solved the problem.
It seems that cloudfare was blocking the aws instance (but no my pc) and for some reason I didn't get a response or error.
I must clarify that I have access to the target API and the posibility to move it, I don't know what can be done if you can't do changes in that env.

Related

DevOps API - C# Retrieve list of Projects using Client Libraries

I am trying to get THIS example to work (.Net Client Libraries example) - however everything I have attempted results in an error:
Basic authentication requires a secure connection to the server.
There is another example using the REST Api at the top of the page I linked and this works perfectly fine. For some reason, I just cant get this working using the libraries!
My code looks like this:
Uri uri = new Uri("http://adtfs:8080/tfs/{MyCompany}");
string personalAccessToken = "MyPATString";
VssBasicCredential credentials = new VssBasicCredential("", personalAccessToken);
using (ProjectHttpClient projectHttpClient = new ProjectHttpClient(uri, credentials))
{
IEnumerable<TeamProjectReference> projects = projectHttpClient.GetProjects().Result;
}
As I mentioned, using the same URL and PAT in the REST API example works fine, but for the libraries, I just cant get beyond the error mentioned above.
Am I missing something or can anyone suggest anything else I could try please?
Change http=>https from http://adtfs:8080/tfs/{MyCompany} to https://adtfs:8080/tfs/{MyCompany} ... easiest answer there was I guess works glad it helped ... but just as precautionary tale, I'll add this for posterity, you should use https anyways if the server supports it (had an app that was working sometimes slow, sometimes fast and I couldn't figure out why until I saw this https://httpvshttps.com, turns out the https tunnel was always being recreated cause I put http instead of https and the server was set to always switch to https).

Google Cloud API not returning any response

Background information:
I'm trying to create a PoC for Google Cloud Vision API using their .NET library.
What I have done:
Create a simple console apps with the following code for Vision API.
GoogleCredential credential = GoogleCredential.FromFile(ConfigurationManager.AppSettings["GoogleCredentialFile"]);
Grpc.Core.Channel channel = new Grpc.Core.Channel(Google.Cloud.Vision.V1.ImageAnnotatorClient.DefaultEndpoint.ToString(), credential.ToChannelCredentials());
var client = Google.Cloud.Vision.V1.ImageAnnotatorClient.Create(channel);
var image = Google.Cloud.Vision.V1.Image.FromFile(#"C:\Users\u065340\Documents\sample.jpg");
var response = client.DetectLabels(image);
foreach (var annotation in response)
{
if (annotation.Description != null)
result = annotation.Description;
}
Problem:
The line client.DetectLabels(image) gets stuck for a long time before ultimately throwing the error Deadline Exceeded.
My code sits behind a corporate proxy, but I have validated that it is not blocking internet access because I can call https://vision.googleapis.com/$discovery/rest?version=v1 from the same apps and get its JSON response just fine.
Any suggestions?
After digging around through github issues related to proxies as suggested by Jon Skeet, I found that Google Cloud Client APIs can be generally divided into 2 categories (Ref: here): REST-based HTTP 1.1 with JSON and gRPC.
For APIs associated as REST-based, there should be no issue with proxies. The problem starts to appear when we are using gRPC-based APIs such as Google Cloud Vision and Google Speech. In gRPC, we need to explicitly provide our proxy server information.
For those using Java Client, it seems we still can't set proxy properly because it will eventually be ignored, and causing the Deadline Exceeded error. This issue is already well known and can be found at here and further traced into here.
The Google team has determined that it is indeed a bug, and the status remains Open.
As for C# Client, we can set proxy information using gRPC Environment Variables which is documented in here. The code is Environment.SetEnvironmentVariable("http_proxy", <your_proxy_server>);
After I set the http_proxy environment variable pointing to my proxy server, all is well again. I get the expected output "This API needs Billing Account".
Many thanks to Jon Skeet for pointing me in the right direction :D

Using GET request causes bot dialog to fail

I've connected my bot application to the direct line API which is published with Azure. I am currently testing the application with a command line client application, the bot framework emulator, and the dev.botframework.com homepage for my bot.
Everything works correctly until I attempt to submit a GET request to a REST API. I've tested the GET API request in a separate project and it works correctly and the GET request worked prior to implementing the direct line channel. Is there anything I need to be aware of when making http requests with the direct line on the bot side?
Code in question
using (var client = new HttpClient())
{
client.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Basic", headerParam);
var response = client.GetAsync(new Uri("someUrl.com/api/v1/auth")).Result;
string content = response.Content.ReadAsStringAsync().Result;
var jo = JObject.Parse(content);
this.token = jo["Result"]["Token"].ToString();
}
await context.PostAsync(this.token);
the line that actually causes the failure is
var response = client.GetAsync(new Uri("someUrl.com/api/v1/auth")).Result;
Also is there an easier way to debug a project when it's published to azure and running direct line API?
System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: An attempt was made to access a socket in a way forbidden by its access permissions ipaddress
I have tried to invoke my custom REST API within my bot application back-end, then I could leverage Remote debugging web apps to retrieve the result from my bot application hosted on Azure web app as follows:
After searching for the related issue, I found that there be limitation for the number of sockets of your current app service plan when creating the new outgoing connections. You could try to scale up your App Service plan or create a new web app to isolate this issue. For more details, you could refer to this similar issue and this blog.

Slow WebClient.DownloadString?

I'm working on a web application that runs with ASP.Net 3.5
Somewhere in the application, I'm making calls to an external system. This call consists on downloading a string from a specific url :
string targetUrl = BuildMyUrl();
WebClient wc = new WebClient();
string data = wc.DownloadString(targetUrl);
This code works quite well with a acceptable response time (under 500ms).
However, in specific cases this response time is over 15 seconds. I can reproduce the behavior, and I can clearly see the long time is on the DownloadString call.
I don't understand why this occurs in my scenario.
You will say : "Hey, it's the target system that is slow". But I was not able able to reproduce the behavior outside my application (I've build a small console application that isolate the faulting code. Never get any issue).
I don't know where to look now to understand the issue. What can cause a simple download data to be be lengthy ?
FYI: the target system is an authentication service. The target url is of kind :
httpS://mysystem/validate?ticket=XXXYYY
Maybe the https protocol is the issue.
Does using WebClient class under IIS can alter the behavior of the WebClient ?
[Edit] I've tried :
To explicitly set the Proxy property of the WebClient object to null
I've replaced the DownloadData call by this code :
var req = (HttpWebRequest)WebRequest.CreateDefault(new Uri(targetUrl));
using (var response = (HttpWebResponse)req.GetResponse())
{
using (var sr = new StreamReader(response.GetResponseStream()))
{
data= sr.ReadToEnd();
}
}
None of this test were successful.
Try to use Fiddler or some integrated network analyzer inside Chrome/FF browsers to see the HTTPS requests/responses and their headers.
The latency was due to a certificate validation timeout. One of the issuer in the chain was not correctly deployed in the client server.

Using WCF service in MonoTouch with Authentication

I am using a WCF service client generated by slsvcutil form Silverlight toolkit version 4. I've also tried version 3 with the same problems. When I use a client instance running on http with no user credentials it runs without problems. But I need to switch to https for productive servers and send user credentials that are hardcoded for my application. I use the following code for that:
var binding = new BasicHttpBinding (BasicHttpSecurityMode.TransportCredentialOnly);
var endpoint = new EndpointAddress (AppSettings.FlareEndPoint);
_service = new TopicAnalystAPIClient(binding, endpoint);
_service.ClientCredentials.UserName.UserName = "xxx";
_service.ClientCredentials.UserName.Password = "xxx";
When I call a method on that service pointing to http with no authentication it works. When I use the this code against http/https with the credential I get "There was an error on processing web request: Status code 401(Unauthorized): Unauthorized" exception. I've checked that the credentials are correct, I am able to open the service reference in my browser. I've also tried several combinations of http/https and SecurityMode value. I've also tried it on four different servers always with the same result.
What can be the problem?
A lot of permutations are possible. BasicHttpSecurityMode.TransportCredentialOnly should be usable without SSL [1] using HTTP itself. This means the server will send one (or more) authentication method(s) to the client (e.g. basic, digest, ntlm) and Mono (including MonoTouch) should be providing support for the most of them.
It is possible that the linker (if used) removes one of them. In that case you could try building and testing without linking (or skip linking of System.Net.dll).
It's also possible that the authentication method that the serve insist on is not supported. You could find which one is used by running a network trace (e.g. wireshark) or, maybe, it will show up in more details in the server log (along with the 401 error).
[1] http://msdn.microsoft.com/en-us/library/system.servicemodel.basichttpsecuritymode%28v=vs.95%29.aspx

Categories