I've set up a graphite and grafana instance, both on the same machine, but with different vhosts (using Apache) to be able to access both independently from each other.
It runs fine, but as soon as I try to put up a basic authentication on the graphite instance, grafana cannot read the data anymore. I've modified the config.js source from Grafana to include the username and password for the graphite instance (as seen in the snippet below).
When I open the Grafana row editor, I see the renderer not using the username + password (in reuqest -> url). I see there:
http://graphite.my-server.de:80/render
How can have Grafana use the username+password to access graphite?
Thanks!!
// Graphite & Elasticsearch example setup
datasources: {
graphite: {
type: 'graphite',
url: "http://adminuser:mypassword#graphite.my-server.de:80",
},
elasticsearch: {
type: 'elasticsearch',
url: "http://adminuser:mypassword#graphite.my-server.de:9200",
index: 'grafana-dash',
grafanaDB: true,
}
},
The problem was with an apache setting. Debugging with Google Chrome and the dev tools plugin showed the issue. Needed to add those headers:
Header set Access-Control-Allow-Origin "http://grafana.my-server.de"
Header set Access-Control-Allow-Credentials true
Header set Access-Control-Allow-Methods "GET, OPTIONS"
Header set Access-Control-Allow-Headers "origin, authorization, accept"
It looks like your browser cache config.js with previous settings.
Try to use clear cache or use another browser.
And, are you sure that elasticsearch have the same basic auth login and password?
Related
So it seem like in next.config.js our previous devs coded some pernament redirects like so:
{
source: '/some-path',
destination: 'https://storage.googleapis.com/company/some-path.html',
permanent: true
}
Here's doc: https://nextjs.org/docs/api-reference/next.config.js/redirects
Now we would like to disable that redirect, and use normal page thats generated within next.js app.
I've removed the redirect from next.config.js, but since it used "permament" param it seems like the redirect is cached in browser (if user visited that redirect previously they'll have to clear cache to actually see the new page, since it uses response code 308 Permament Redirect).
I've found two possible solutions:
change the url we're using so the cache wont trigger redirect
set redirect on that external site back to our page (seems like dirty solution)
Is there other way to fix this? Or maybe default next.js redirect cache has some validation time and it will be fine in few days or something?
You can add the Cache-Control and Expires headers to delete cache.
Example from docs:
async redirects() {
return [
// if the header `x-redirect-me` is present,
// this redirect will be applied
{
source: '/:path((?!another-page$).*)',
has: [
{
type: 'header',
key: 'x-redirect-me',
},
],
permanent: false,
destination: '/another-page',
},
// ....
I am trying to get a remote web page into an iframe in my project. When i try to open my project web site the browser console displays below error and not showing page in iframe.
Nginx Refused to display 'http://www.xxxxx.com/' in a frame because it set multiple 'X-Frame-Options' headers with conflicting values ('DENY, ALLOW-FROM http://www........com'). Falling back to 'deny'.
I also added below line in nginx xconf:
add_header X-Frame-Options "ALLOW-FROM http://www.......com";
There is no X-Frame-Options = Deny configuration in any place in my Nginx configurations.
But still, when I run the page it shows multiple headers. It is like Deny is hardcoded default. But I just added 1 header (ALLOW-FROM).
Where does the other header (DENY) come from, I don't understand. How can I bypass this deny header which is coming with the response page when I insert it into the iframe?
I also used Chrome Extension Requestly that can be used to add/remove/modify response headers. It works when I use the Requestly extension on my machine.
But I can't use a chrome extension-based solution as the site is public and everyone does not use Requestly. So I am looking for an Nginx-config based solution or any server-side solution to remove this header.
I solved this problem in Django settings, commenting some middleware lines and adding some variables. 178.62.107.96 is the server in which we create iframe and insert django server created web page :
MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
#'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
#'django.middleware.clickjacking.XFrameOptionsMiddleware',
]
X_FRAME_OPTIONS = 'ALLOW-FROM 178.62.*.*'
CSRF_TRUSTED_ORIGINS = ['178.62.*.*']
CSRF_COOKIE_SAMESITE = None
How can I disable the cache for a specific URL?
I got for example my Administration panel in url:
/admin/
front is of course:
/
The problem is when someone updates e.g. page title, he needs to refresh 2-3 times to see the change in the list, how can I disable cache for all after /admin url?
Symfony does not cache HTTP responses by default.
Maybe check your webserver config if the Cache-Control/Expires directives are injected into the response there.
Static files in my app are uploaded to GCS and are set to public links.
when a static resource is requested (in this case a font) it hits a url like https://example.com/static/fonts/font.woff
the server then redirects the request to the apropriate GCS url to be served.
the problem here is that with chrome i get this CORS issue:
xxxxxxxxe3b8ccc0e3:1 Font from origin 'https://storage.googleapis.com' has been blocked from loading by Cross-Origin Resource Sharing policy: A wildcard '*' cannot be used in the 'Access-Control-Allow-Origin' header when the credentials flag is true. Origin 'https://example.com' is therefore not allowed access.
the CORS defaults on the bucket and all subfolders is set like so:
[{"origin": ["*"], "responseHeader": ["Content-Type"], "method": ["GET"], "maxAgeSeconds": 3600}]
the question is where is this credentials flag set?
i do redirect to the public link so its not an ajax request, the link is in the font-face declaration of the css file.
also it is not an option to set the origin to a specific domain or list of domains because my app is multitenant and there are multiple different domains accessing the same file.
this seems to work correctly when the request comes from http but gives this error when on https
also this works as expected in safari but does not with chrome.
Such issues, when hosting fonts on GCS, could also be related to missing CORS configuration on the GCS bucket.
(See https://cloud.google.com/storage/docs/cross-origin).
You may define cors access settings with:
gsutil cors set cors-config.json gs://my-bucket
And your cors-config.json could be, for example:
[
{
"origin": ["*"],
"responseHeader": ["Content-Type"],
"method": ["GET"],
"maxAgeSeconds": 3600
}
]
Meaning ok to read from all origins.
Edit from 2019: Chrome fixed this years ago!
Interesting! There is a Chrome bug (issue 544879) in which Chrome insists that it needs credentials for loading fonts, even though it does not. Looks like that's likely to be your problem.
While you wait for that bug to be fixed, you may consider these options:
Use HTTP instead of HTTPS when referencing storage.googleapis.com. HTTP may not be vulnerable to this problem.
List specific domains instead of a wildcard in yours CORS policy.
Rather than hosting a font and referencing it with #font-face, host a CSS file with the font encoded as a data URI. Example: https://www.filamentgroup.com/lab/font-loading.html
In our case, the issue was that we naively used the storage.cloud.google.com/path/to/resource public URL as the base Url for our front-end application, while it does not allow CORS request...😓
Instead, we had to use the storage.googleapis.com/path/to/resource one!
More information on our CORS is handled by google cloud
I'm working with apache on my local instance and nginx on production.
I have a javascript application that is setting headers in API calls to authenticate the user. It's working fine on local with my apache server. However for some reason, my custom headers are ignored by Nginx.
I tried to add this line in my site configuration:
add_header 'Access-Control-Allow-Origin' '*';
But it still ignore the headers.
Does anyone know where I should look to bypass this ?
Cheers,
Maxime
I found what was the issue.
My custom headers were API_USER and API_TOKEN.
There is a directive in Nginx that says to ignore headers with a '_' in the name, more info here
So I've updated my custom headers to x-api-user and x-api-token and now it's working like a charm !