No 'Access-Control-Allow-Origin' header for Grafana - angularjs

Question

I'm trying to setup Grafana on top of nginx. Here's how my current setup is. Grafana is supposed to talk to both graphite and elastic search on the same server.
Here's my nginx configuration file. I'm not sure what's wrong in this configuration:
#graphite server block
server {
listen 8080 ;
access_log /var/log/nginx/graphite.access.log;
error_log /var/log/nginx/graphite.error.log;
location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:3031;
}
}
#grafana server block
server {
listen 9400;
access_log /var/log/nginx/grafana.access.log;
error_log /var/log/nginx/grafana.error.log;
location / {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
add_header Access-Control-Allow-Origin 'http://54.123.456.789:9400';
add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE';
add_header 'Access-Control-Allow-Headers' 'Authorization, Content-Type, origin, accept';
add_header 'Access-Control-Allow-Credentials' 'true';
root /usr/share/grafana;
}
}
Now, whenever I try to run Grafana, it gives me the following error:
XMLHttpRequest cannot load http://54.123.456.789:8080/render. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://54.123.456.789:9400' is therefore not allowed access.
Can someone please help me out in this? Thanks in advance.

Answer 1

Try putting the four lines of Access-Control-Allow-* in the configuration of the graphite server.
To my mind, grafana is asking graphite and that's graphite who has to allow Grafana.

Answer 2

Ok I wasn't specifically setting up Graphana, but I was intending CORS to work with the auth_basic directive from nginx because such directive overrides any headers that you had before whenever authentication is required (When the server returns a 401 basically)
So after a copule hours of research I found this Gist: https://gist.github.com/oroce/8742704 which is specifically targetted to Graphana and possibly gives a complete answer to this question.
BUT for my particular purposes, which again were to combine auth_basic with CORS headers via add_header, my take away from that Gist is the following:
Your server location should follow a structure like the one below:
location / {
proxy_pass <PROXY_PASS_VALUE>;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Any additional headers and proxy configuration for the upstream...
# Remove the CORS Origin header if set by the upstream
proxy_hide_header 'Access-Control-Allow-Origin';
# Add our own set of CORS headers
# The origin specifically, when using ith with authentication CANNOT be set to * as per the spec, it must return 1 and only 1 value so to mimic "*"'s behavior we mirror the origin
add_header Access-Control-Allow-Origin $http_origin;
add_header Access-Control-Allow-Methods
'GET,POST,PUT,DELETE,OPTIONS';
add_header Access-Control-Allow-Headers 'Authorization';
add_header Access-Control-Allow-Credentials 'true';
if ( $request_method = 'OPTIONS' ) {
# If request method is options we immediately return with 200 OK
# If we didn't do this then the headers would be overwritten by the auth_basic directive when Browser pre-flight requests are made
return 200;
}
# This should be set AFTER the headers and the OPTIONS methos are taken care of
auth_basic 'Restricted';
auth_basic_user_file <HTPASSD_FILE_PATH>;
}
Then when using this from a browser environment, you could issue the following:
fetch(
'<URL>',
{
method: 'POST',
body: <YOUR_BODY_OBJECT>,
// This must be set for BASIC Auth to work with CORS
credentials: 'include'
}
)
.then( response => response.json() )
.then( data => {
console.log( data );
} );