0

I have been building a weather widget with JavaScript.

I use angularjs ($http method:get) to make the api calls.

I have had no problem getting weather information using below API call (my api key is removed)

http://api.openweathermap.org/data/2.5/weather?q=Manchester,uk&appid=xxxxxxxx&units=metric

But when I wanted to switch to a different API (URL below) I get the error

XMLHttpRequest cannot load https://api.forecast.io/forecast/33.499318,-2.234089000000026?units=si. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:50301' is therefore not allowed access.

Is this because the second API uses HTTPS? but it doesn't make sense. why was the first api allowed?

Menol
  • 1,230
  • 21
  • 35

2 Answers2

0

Is this because the second API uses HTTPS?

No, it is because the first API included a 'Access-Control-Allow-Origin' header to give you permission.

Why was the first api allowed?

Because the supplier of the first API explicitly makes it available to client side JavaScript hosted on other websites.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • 1
    so is it a setting at the API providers end? – Menol Feb 26 '16 at 11:44
  • 1
    @Menol — Well. Yes. Obviously. As I said — *the first API included a 'Access-Control-Allow-Origin' header* — It could hardly come from anywhere else if that was where I said it came from. – Quentin Feb 26 '16 at 11:45
  • @Quentin easy language plz. Hard to get the comment. – Jai Feb 26 '16 at 11:47
  • Isn't "yes" easy enough? – Quentin Feb 26 '16 at 11:47
  • How do you propose that the attacker makes the server (which they don't control) tell the browser (which they don't control) that it is safe for the attacker's JavaScript to read the data the site is giving to the browser? – Quentin Feb 26 '16 at 12:56
  • as far as my knowledge is concerned XSS attacks involve injecting JS scripts to call attackers APIs to send stolen data in which case attacker has full control over his APIs response headers. Anyway, after reading a bit I believe that this header is not intended to prevent XSS but to protect resources. – Menol Feb 26 '16 at 13:39
0

Thanks to @Quentin's mention about the Access-Control-Allow-Origin header I found below described is the reason why one api was blocked while the other was allowed.

My first (successful) API was sending below header with its response:

Access-Control-Allow-Origin:*

And the second (failed) API didn't send this header, which is why browsers refuse to display the response on my domain.

About The Access-Control-Allow-Origin header

Web resources such as APIs send this header along with their responses to avoid or limit the use of their resources by other domains in cross-site manner.

e.g. If domain A.bc adds below header to its resources 

Access-Control-Allow-Origin: http://foo.example

then only foo.example can access resources in a cross-site manner.

If you want to read more, then this header goes under HTTP access control (CORS) which is fully explained here.

This SOF answer also has a great explanation: How does Access-Control-Allow-Origin header work?

Community
  • 1
  • 1
Menol
  • 1,230
  • 21
  • 35