I am trying to add "add_header" to nginx but the reload is failing:
add_header
add_header Allow "GET, POST, HEAD" always;
When I run nginx -t, it points to this line mentioning I am passing too many parameters. Any idea what I am doing wrong?
url for add_header:
http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header
You have an old nginx.
always flag was added in nginx 1.7.5
Related
I need to add the below X-Frame options in the nginx CF.
add_header X-Frame-Options "SAMEORIGIN";
I am using Cloud Foundry Staticfile buildpacks.
If I edit nginx.conf directly, it is getting removed whenever I deploy my application. So it is recommended to added through Staticfile buildpack.
But I don't know the exact value for the x-frame options.
Reference: https://docs.cloudfoundry.org/buildpacks/staticfile/index.html
Correct, you do not want to edit the config file directly. Your change will disappear the next time your app is restarted, restaged, recreated, crashes or even the next time the platform moves the app due to maintenance.
If you follow the instructions for adding custom Nginx configuration, you can put the configuration into a snippet & the Nginx configuration generated by the Staticfile buildpack will automatically read your config snippet.
Hope that helps!
Nginx.conf file Enable X-Frame-Options
location ~* \.(?:html)$ {
try_files $uri =404;
add_header Cache-Control 'no-cache, no-store, must-revalidate, max-age=0';
add_header X-Frame-Options 'SAMEORIGIN';
add_header X-Frame-Options 'DENY';
add_header Content-Security-Policy "frame-ancestors 'self';";
expires 0;
}
I'm using nginx as a reverse proxy for my website.
I want to be able to open my website in an iFrame from a chrome extension new tab html file.
For this, I need my nginx to set X-Frame-Options to allow all domains.
According to this answer, all domains is the default state if you don't set X-Frame-Options.
My /etc/nginx/nginx.conf doesn't have the X-Frame-Options set anywhere.
Yet when I check my website response header using Postman, it shows me X-Frame-Options = SAMEORIGIN.
How can I remove this setting and load my website in an iFrame in the chrome new-tab .html file?
Solved it by changing proxy_hide_header values in /etc/nginx/sites-available/default file like so:
proxy_hide_header X-Frame-Options;
Needed to restart nginx as well as use pm2 to restart my nodejs server (for some reason, it didn't work till I made a small change to my server and restarted it).
add_header X-Frame-Options ""; did the trick for me in nginx 1.12.
Found this header in /etc/nginx/snippets/ssl-params.conf
Just needed to comment out the line:
# add_header X-Frame-Options DENY;
I found this header option in the file /etc/nginx/templates/default.conf.
add_header X-Frame-Options "SAMEORIGIN" always;
default.conf file is mentioned in my main nginx.conf file.
maybe you can try adding this in your nginx config
add_header X-Frame-Options "" always;
it works for me
OS: Ubuntu 14.04
Nginx: nginx version: nginx/1.4.6 (Ubuntu)
For providing Clickjacking based security in the browser side for frames, X-Frame-Options header options can be set in 3 different ways.
DENY
SAMEORIGIN
ALLOW-FROM <uri>
PS: https://www.owasp.org/index.php/Clickjacking_Defense_Cheat_Sheet (for compatibility matrix) and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options (Note: Don't mix Apache with Nginx for configuration part).
I want to enable display of frames / iframes (generated/provided by Log parser plugin) on my Jenkins machine i.e. on Jenkins job's dashboard. For more info you can see some background here: Jenkins Log parser plugin - parsed console log page is not showing Load denied by X-Frame-Options does not permit framing ERR_BLOCKED_BY_RESPONSE
For that, I need to make sure, the following lines is NOT present in my NGINX configuration for jenkins https conf file / or you can commment it out.
add_header X-Frame-Options DENY;
Comment this line and the frames will render fine now in your browser i.e. on job's dashboard but doing this will bring security issues.
To implement the second option is to make sure, you remove/replace the above line OR make sure the following line EXIST in your NGINX config file for Jenkins https conf.
add_header X-Frame-Options SAMEORIGIN;
Now, the 3rd approach takes the word ALLOW-FROM https://_URI_value with / without double quotes starting before ALLOW-FROM and ending after the URL part.
This will tell NGINX to allow rendering of frames where the are coming from the given URI (JENKINS URL in my case), so I tried the following:
#ALLOW-FROM https://my.company.jenkins.com/
#add_header X-Frame-Options ALLOW-FROM https://my.company.jenkins.com/
#add_header X-Frame-Options "ALLOW-FROM https://my.company.jenkins.com/"
If I enable just the first line (as listed above for the 3rd approach) and run sudo service nginx restart; sleep 1; tail -1 /var/log/nginx/error.log, then I'm getting the following output / error.
* Restarting nginx nginx [fail]
2017/08/24 15:27:39 [emerg] 127120#0: unknown directive "ALLOW-FROM" in /etc/nginx/sites-enabled/jenkins_https.conf:23
If I enable either just the 2nd or 3rd line (as listed above for the 3rd approach), then I'm getting the following output / error for both 2nd/3rd lines.
* Restarting nginx nginx [fail]
2017/08/24 15:29:49 [emerg] 127189#0: invalid number of arguments in "add_header" directive in /etc/nginx/sites-enabled/jenkins_https.conf:23
How can I successfully, use the ALLOW-FROM syntax within nginx config file while the restart succeeds without the above failures and it allow frames/iframes rendering coming from a given URI/URL?
PS:
Using add_header X-Frame-Options SAMEORIGIN;, my issue is resolved but I'm mainly looking for why ALLOW-FROM <URI/URL> syntax is not working and giving me the above error messages.
The syntax accepted above doesn't work.
The expected syntax is
add_header X-Frame-Options "allow-from https://my.example.com/";
Tested successfully on versions nginx/1.11.9 and nginx/1.15.9
You've probably already figured this out, but just for posterity: to specify allow-from in add_header, use this syntax:
add_header "allow-from https://my.example.com/";
I am having trouble making cross site ajax calls. Using nginx, I believe I have added the right headers in the server configuration, but it still does not work in my JS code or in the console. I wonder what I am doing wrong.
Here is what I type into the console the response is the familiar "No 'Access-Control-Allow-Origin' header is present" error:
$.get("//www.example.com");
Object {readyState: 1, getResponseHeader: function, getAllResponseHeaders: function, setRequestHeader: function, overrideMimeType: function…}
XMLHttpRequest cannot load http://www.example.com/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://dictionary.aherriot.com' is therefore not allowed access.
When I look at the response headers from my initial webpage load, I do see the following headers:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:X-Requested-With,Accept,Content-Type, Origin
Access-Control-Allow-Methods:GET, POST, OPTIONS, PUT, DELETE
Access-Control-Allow-Origin:*
and here is the nginx config file for the site:
server {
listen 80;
root /home/aherriot/sites/dictionary;
index index.html index.htm;
server_name dictionary.aherriot.com;
location / {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' 'true';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
add_header 'Access-Control-Allow-Headers' 'X-Requested-With,Accept,Content-Type, Origin';
}
}
I am stumped as to what I am missing. What else do I need to do to allow CORS? Thank you.
You can use * to accept all origin but it will prevent using 'Access-Control-Allow-Credentials: true'.
Take a look here for more examples - http://enable-cors.org/server_nginx.html
The problem with the question is there is a fundamental misunderstanding of what CORS is. It is not for the origin server to specify which third-party domains a page can access through XMLHttpRequest requests, but rather it is the server on an external domain that specifies which domains can connect to it.
I want to add a custom header for the response received from the server behind nginx.
While add_header works for nginx-processed responses, it does nothing when the proxy_pass is used.
add_header works as well with proxy_pass as without. I just today set up a configuration where I've used exactly that directive. I have to admit though that I've struggled as well setting this up without exactly recalling the reason, though.
Right now I have a working configuration and it contains the following (among others):
server {
server_name .myserver.com
location / {
proxy_pass http://mybackend;
add_header X-Upstream $upstream_addr;
}
}
Before nginx 1.7.5 add_header worked only on successful responses, in contrast to the HttpHeadersMoreModule mentioned by Sebastian Goodman in his answer.
Since nginx 1.7.5 you can use the keyword always to include custom headers even in error responses. For example:
add_header X-Upstream $upstream_addr always;
Limitation: You cannot override the server header value using add_header.
Hide response header and then add a new custom header value
Adding a header with add_header works fine with proxy pass, but if there is an existing header value in the response it will stack the values.
If you want to set or replace a header value (for example replace the Access-Control-Allow-Origin header to match your client for allowing cross origin resource sharing) then you can do as follows:
# 1. hide the Access-Control-Allow-Origin from the server response
proxy_hide_header Access-Control-Allow-Origin;
# 2. add a new custom header that allows all * origins instead
add_header Access-Control-Allow-Origin *;
So proxy_hide_header combined with add_header gives you the power to set/replace response header values.
Similar answer can be found here on ServerFault
UPDATE:
Note: proxy_set_header is for setting request headers before the request is sent further, not for setting response headers (these configuration attributes for headers can be a bit confusing).
As oliver writes:
add_header works as well with proxy_pass as without.
However, as Shane writes, as of Nginx 1.7.5, you must pass always in order to get add_header to work for error responses, like so:
add_header X-Upstream $upstream_addr always;
There is a module called HttpHeadersMoreModule that gives you more control over headers. It does not come with Nginx and requires additional installation. With it, you can do something like this:
location ... {
more_set_headers "Server: my_server";
}
That will "set the Server output header to the custom value for any status code and any content type". It will replace headers that are already set or add them if unset.
You could try this solution :
In your location block when you use proxy_pass do something like this:
location ... {
add_header yourHeaderName yourValue;
proxy_pass xxxx://xxx_my_proxy_addr_xxx;
# Now use this solution:
proxy_ignore_headers yourHeaderName // but set by proxy
# Or if above didn't work maybe this:
proxy_hide_header yourHeaderName // but set by proxy
}
I'm not sure would it be exactly what you need but try some manipulation of this method and maybe result will fit your problem.
Also you can use this combination:
proxy_hide_header headerSetByProxy;
set $sent_http_header_set_by_proxy yourValue;