We Keep Coding

C# API call from MarketStack and print values - Error 403

I would like to make a successful API call, then print the values in order to see if it works. My main goal is to analyze the data, after I can make a successful API call, and build a systematic strategy for trading.
System.Net.Http.HttpRequestException: "Response status code does not indicate success: 403 (Forbidden)
namespace marketstacktest
{
class Program
{
static async Task Main(string[] args)
{
Console.WriteLine("Hello World!");
var options = Options.Create(new MarketstackOptions() { ApiToken = "secretTokenHere" });
var marketstackService = new MarketstackService(options, NullLogger<MarketstackService>.Instance);
var appleSymbol = "AAPL";
var fromDate = DateTime.Now.AddDays(-200);
var toDate = DateTime.Now;
//error at the await System.Net.Http.HttpRequestException: "Response status code does not indicate success: 403 (Forbidden)."
List<Marketstack.Entities.Stocks.StockBar> stock = await marketstackService.GetStockEodBars(appleSymbol, fromDate, toDate);
foreach (var stock_i in stock)
{
Console.WriteLine($"close: {stock_i.Close}");
}
}
}
}

In the API manual, which is directly linked from the github, it gives information about all of the error codes. The relevant ones here are these two:
Code
Type
Description
403
https_access_restricted
HTTPS access is not supported on the current subscription plan.
403
function_access_restricted
The given API endpoint is not supported on the current subscription plan.
Their class library on github is just wrapping a json REST api. Every call to the API is just an http request, returning data as json objects. The 403 error indicates that your request was accepted as a valid request, but intentionally rejected by the server for some reason. And according to the docs, the error was because your account is not allowed access to either https or to the type of request.
Their free-tier subscription only includes end-of-day data, which is what you requested, so it wouldn't make sense for that not to be allowed. So, your app is almost certainly making an https call.
I went to the examples at the very beginning of their quick start guide, and chose the end-of-day example to match your app, and clicked on the link. It worked, and gave a bunch of json records. But, the request they made was using 'http' not 'https'.
Changing the requst to 'https' elicited a 403 response with this content (formatted for readability):
{
"error":
{
"code": "https_access_restricted",
"message": "Access Restricted - Your current Subscription Plan does not support HTTPS Encryption."
}
}
At this point we have enough to be almost certain that this is your issue. The final thing is to go look up how to turn https requests off in their class library. To avoid having to go through the code, I checked the help at the bottom of the page one more time, and found this (formatted for readability):
var options = Options.Create(new MarketstackOptions(){
ApiToken = apiKey,
MaxRequestsPerSecond = 3,
Https = true
});
Welp. This should probably be in their first example, since that's what people are most likely to try first, but it's not. So, to stop trying to make http requests, you just need to set the Https option to false in your code. You just need to add that to the options in your code, like so:
var options = Options.Create(new MarketstackOptions(){
ApiToken = "secretTokenHere",
Https = false
});
I will leave the testing to you, but from the browser test, we know that the request should work, unless there's a bug in their library. Given the information that was available, this is almost certainly the issue.

How to send GET request from internet explorer to Asp.Net Core API?

I am developing Asp.Net Core 3.1 API, Everything working as expected when I send a GET request from google chrome, Edge, Postman. But when I send GET request from internet explorer it starts to download a file default.json with the content as the response of GET request.
Defualt Action method:
public IEnumerable<string> Get()
{
return new string[] { "Welcome" };
}
default.json content:
[
"Welcome"
]
I search on the internet but could not find anything useful.
FVI, I have the same observation when I run the API using visual studio or the deployed API on the server using IIS.
IE Version: 11.900.18362.0
So I have to questions.
Does IE not support this, Is this default behavior of IE?
If Yes then how can it be fixed?

This is IE default behavior, and comes down to it simply doesn't know how to treat content with mime types like */json, hence suggest a download.
Assuming this is for users in general, and you simply want to display the json data in a browser, you could convert the content server side to text.
public ContentResult Get()
{
var jsondata = new string[] { "Welcome" };
return Content(JsonSerializer.Serialize(jsondata));
}
If you are going to do something with the actual json data, which one usually does when consuming an api, you will use some kind of client side script (e.g. Ajax as in below sample, or similar) to get the content, and in those cases there won't be any problem, like the one you encountered.
var xhr = new XMLHttpRequest();
xhr.open('GET', '/api/your-method', true);
xhr.onload = function (e) {
if (this.status == 200) {
var jsonstring = this.responseText;
// do something with the json string, e.g. JSON.parse(jsonstring)
}
};
xhr.send();
Here's a couple of posts that suggests to change the registry, though they won't be viable unless it is for a local computer of your own (and if it is, picking a browser that works out-of-the-box must be easier).
Display JSON in IE as HTML Without Download
How can I convince IE to simply display application/json rather than offer to download it?
Edit
As suggested in a comment, yet another option would be to change the mime type explicit:
Json response download in IE(7~10)

Verify application for Loader.Io testing

I am trying to do some load testing with
https://loader.io/
I am currently stuck at the stage of "verifying" my localHost application to make sure I am the one controlling it.
I have added this end point:
[HttpGet("/loaderio-a65421134i3ia3d110vcv0120d1ac14b/")]
[Authorize()]
public StreamReader GetLoaderIO()
{
var file = System.IO.File.OpenText(#"C:\Users\User\Downloads\loaderio-a65421134i3ia3d110vcv0120d1ac14b.txt");
return file;
}
When I run a GET request to this URL
http://localhost:5012/loaderio-a65421134i3ia3d110vcv0120d1ac14b/
I successfully step in my end point, what do I need to return in order for the LoaderIO to be happy? Do I have to return the stream so it can be downloaded?

I can see three potential issues with your code.
First, you are targeting a localhost address instead of a deployment address (i.e. http://yourapi.com or 159.254.102.69). To fix that issue you will need to either deploy your code somewhere or open http ports from your machine.
Second the file you are trying to retrieve my not be at the same location or might not even be accessible so a simpler way would be to write the string directly (done multiple time to verify on loader.io works like a charm) like below:
[HttpGet]
[Route("loaderio-a65421134i3ia3d110vcv0120d1ac14b")]
public HttpResponseMessage GetLoaderIoVerification()
{
var response = Request.CreateResponse(HttpStatusCode.OK);
response.Content = new StringContent("loaderio-a65421134i3ia3d110vcv0120d1ac14b", Encoding.UTF8, "text/plain");
return response;
}
Finally, there is that Authorize attribute that will try to authenticate the loader.io request that needs to be a resource as accessible as this one: https://media4.giphy.com/media/LXONhtCmN32YU/giphy.gif In order to do so you will need to remove it.
Once those three points are corrected you will be able to verify your api for loader.io. Hope it helps.

Invalid PUT method from Webforms to Web API 2 (Azure)

I have a Web API in my Azure server and I'm making calls from an ASP.NET Webforms website.
I seem to be able to perform GET with no trouble. Now for the PUT, it's giving me this error:
The page you are looking for cannot be displayed because an invalid
method (HTTP verb) is being used
I was not able to DELETE either. I see some other topics where people disable some WebDav and stuff on their IIS servers and it works. But on Azure?
Below my code for the PUT:
HttpResponseMessage response = client.GetAsync("api/People/" + id).Result;
if (response.IsSuccessStatusCode)
{
var yourcustomobjects = response.Content.ReadAsAsync<People>().Result;
Uri peopleUrl = response.Headers.Location;
yourcustomobjects.name= "Bob";
response = await client.PutAsJsonAsync(peopleUrl, yourcustomobjects);
tbDebug.Text += await response.Content.ReadAsStringAsync();
}

Alright I grew tired of trying to fix this issue by enabling PUT.
So what I did, was I wrote a GET that makes the needed change in the database.
Cheers

Web Security in IE VS Chrome & Firefox (bug)

Why is the Web Security is working differently on different browser:
Details:
I have two applications
One is a simple HTML application and another one is an ASP.NET MVC4 WebApi application and the projects are inside of same solution and i have set multiple start-up project for run the application for same time .
Working version:
I have Used Web Security in the Web API project. I did full implementation of web security...
Login Action Code
// GET api/company
[System.Web.Http.AcceptVerbs("Post")]
[System.Web.Http.HttpPost]
public HttpResponseMessage Login(LoginRequest loginRequest)
{
try
{
if (WebSecurity.Login(loginRequest.EmailAddress, loginRequest.Password, true))
{
var userDetails = new string[2];
userDetails[0] = loginRequest.EmailAddress;
var currentUSerRole = Roles.GetRolesForUser(loginRequest.EmailAddress);
userDetails[1] = currentUSerRole[0].ToString();
HttpResponseMessage response =
Request.CreateResponse(HttpStatusCode.Accepted, userDetails);
return response;
}
else
{
HttpResponseMessage response
= Request.CreateResponse(HttpStatusCode.Unauthorized);
return response;
}
}
catch (Exception e)
{
HttpResponseMessage response
= Request.CreateResponse(HttpStatusCode.Unauthorized);
return response;
}
}
*WebSecurity.Login* is working on all browsers when i call the login method using Ajax.
But I have another method in another controller, That named as CurrentDateAndUser
Code:
[AllowAnonymous]
[System.Web.Http.AcceptVerbs("Get")]
[System.Web.Http.HttpGet]
public HttpResponseMessage CurrentDateAndUser()
{
if (WebSecurity.IsAuthenticated)
{
int userId = WebSecurity.CurrentUserId;
string[] currentDateAndUSerId = new string[2];
currentDateAndUSerId[0] = userId.ToString();
currentDateAndUSerId[1] = DateTime.UtcNow.ToString();
HttpResponseMessage response =
Request.CreateResponse(HttpStatusCode.Accepted, currentDateAndUSerId);
return response;
}
HttpResponseMessage responseNew =
Request.CreateResponse(HttpStatusCode.NotAcceptable);
return responseNew;
}
Issue:
If I call the CurrentDateAndUser method from Microsoft Internet Explorer Using an Ajax call, then everything works. The WebSecurity.IsAuthenticated returns true and is working well.
However,
If I call the CurrentDateAndUser method from Google Chrome Or Mozilla Firefox using an Ajax call, then nothing works. The WebSecurity.IsAuthenticated always returns false.
I don't know why. If you have any idea, then please let me know.
I also found a similar problem (not sure if it is a real issue):
When I run my application with Fiddler, I see a different result:
When i call the CurrentDateAndUser method from IE, the request is:
I can see the Cooke/Login values in above image
But When i call the CurrentDateAndUser method from Chrome And Firefox , the request is:
I can't see the cookie values, meaning that the Web Security.IsAuthenticated property is returning false.
Is it Bug in WebSecurity?????
Edit
My Ajax request code is
function GetCurrentUserId() {
return $.ajax({
method: 'GET',
url: rootUrl + '/api/Common/CurrentDateAndUser',
async: false
}).success(function (response) {
return response[0];
}).error(function () {
toastr.error('Somthing is wrong', 'Error');
})
}
This request does not send the Auth Cookie values to Web API method when I run the application in Chrome and Firefox, however, this request sends the cookie values to the API method, if it is run in IE
i have posted the Image , Please take a look at the above image

The issue is not with web security at all, it's with the way you implement your security. You should never be using a userid, email, or anything important in the cookies.
I would suggest you use the FormsAuthentication class to encrypt and decrypt your cookies, and even so, only store something such as the SessionID plus a custom hash of that session ID to verify your self when you decrypt the cookie
Here is a site that gives a pretty good example: http://www.c-sharpcorner.com/uploadfile/nipuntomar/update-formsauthenticationticket/

There are 3 things around it:
WebSecurity.IsAuthenticated actually returns the value of HttpRequest.IsAuthenticated, which is true if the Forms Authentication cookie has been set and is current. It's not available until the user makes the next request after successfully logging in, which is why you are seeing the behaviour that you describe.
I remember reading on MSDN or someplace, the WebSecurity.IsAuthenticated does not work until the page is fully loaded. Meaning if you login a user in a page and in the same flow of code you check IsAuthenticated, it will NOT return True. For IsAuthenticated to be True the page has to be reloaded or use the better practice; which is to redirect the user to another secured page as soon as the login is successful and in that page check IsAuthenticated.
We had the same issue with Chrome (version 21.0.1180). Despite that we see expiration date on Header, some Chrome in Windows XP ignored it. Then we removed the Expiration Date and Chrome accepted keep the session cookie without problems.
So what to do is:
After login try to check this on new page not on same page.
Also try to set cookie explicitly
System.Web.Security.FormsAuthentication.SetAuthCookie(user.Username, false);

I don't know if this will help or not.
But I remember I was learning jQuery ajax
So I setup a simple project on my laptop. When I tested it, it worked fine on IE, but failed in Chrome. After searching for hours, I found that Chrome will not allow AJAX requests from the local machine. When I tested it using an actual web server it worked fine for IE and Chrome.
So my question and advice is: are you testing on the same machine?
Try to deploy it to a machine running a web server with a unique domain name and test your application!