I am following nginx - read custom header from upstream server . My requirement is to read a http header and send it as a cookie to upstream server
So I have following code in location block
if ($http_remote_user){
add_header Set-Cookie UCM_INFO=$http_remote_user;
}
I can see in logs(error.log) that I am getting the value of remote_user but the above mentioned block is not getting executed.What could be the issue?
Posting the answer so that it helps others.I was able to figure out the solution.Since I had unserscores in headers so nginx was rejecting the headers.
So we need to put below in conf file
underscores_in_headers on
Restarted the server and viola it worked.
Related
I have an octoprint server running at http://192.168.1.205. I also have an nginx server hosting myDomain. I want to be able to use the nginx server to pass on a request for http://myDomain/octo to http://192.168.1.205 using a reverse proxy. Here is my nginx code...
server {
server_name myDomain;
location /octo/ {
rewrite ^/octo/(.*) /$1 break; #strip /octo from url
proxy_pass http://192.168.1.205;
}
}
The first http://myDomain/octo request is passed on to http://192.168.1.205 correctly. But after the first response the code in the client makes another request to http://myDomain/moreUri. Since this uri doesn't have /octo nginx doesn't know to send it to http://192.168.1.205/moreUri. Is there a way to have nginx change something in the first response so that the client then makes following requests to http://myDomain/octo/moreUri?
I was able to accomplish this for a case where the octoprint server responded with a redirect. I used ...
proxy_redirect http://192.168.1.205/ http://myDomain/octo/;
and it worked. But that only works on redirects and the following requests were wrong again.
Is there a way to have nginx change something in the first response so
that the client then makes following requests to
http://myDomain/octo/moreUri?
I am not aware that this is possible.
What about to adjust the nginx configuration accordingly ? using location / to process all requests within that block and add an additional redirect directive to address the "Since this uri doesn't have /octo nginx doesn't know to send it to http://192.168.1.205/moreUri" should do the trick.
server {
server_name myDomain;
location / {
rewrite ^/octo/(.*) /$1 break; #strip /octo from url
rewrite ^/(.*)/(.*) /octo/$2 break; #rewrite /moreURI to /octo/moreURI
proxy_pass http://192.168.1.205;
}
}
No matter if the above nginx reconfiguration fixes your issue, i assume the root cause why you need to configure the nginx as reverse proxy in this way might be a misconfigured (or not optimally configured) application. Check the config file if it is possible to configure the applications base path. If so, set it to /octo/ (so the application itself prepends /octo/ to all the links it presents to the user and all requests to the backend automatically) and adjust the rewrite rules accordingly.
I am trying to use nginx as a proxy so that i can hit an API directly from a browser.
Currently. I wrote the nginx line below,
location /binance-api {
add_header Access-Control-Allow-Origin *;
rewrite ^/binance-api/(.*) /$1 break;
proxy_pass http://api.binance.com;
}
Basically whenever i try to hit the server containing nginx
http://nginx-server/binance-api/
I want nginx to hit http://api.binance.com instead.
But for some reason, judging by inspecting XHR responses, my request URL itself keeps getting redirected to https://api.binance.com and CORS would trigger and my request will fail.
What am I missing here?
Thanks
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/";
here is the thing
everything works well before I use nginx.
on server, I deployed a mobile app server using mup, and after using nginx I got a
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http ://meteor.local' is therefore not allowed access.
and then I think I should add the header in nginx, so I add the following in nginx
add_header Access-Control-Allow-Origin $http_origin;
then I got
The 'Access-Control-Allow-Origin' header contains multiple values 'http ://meteor.local, http: //meteor.local', but only one is allowed. Origin 'http: //meteor.local' is therefore not allowed access
and if I change the add_header with
add_header Access-Control-Allow-Origin *;
then I got
The 'Access-Control-Allow-Origin' header contains multiple values 'http: //meteor.local, *', but only one is allowed. Origin 'http: //meteor.local' is therefore not allowed access
I want to know how to fix this and what happens here.
btw, I have tried
http://enable-cors.org/server_meteor.html, and I have App.accessRule("*"); in my mobile-config.js
plus:
my server is deployed at 8001 port, but I got an info say that
XMLHttpRequest cannot load http: //my.site.com/__cordova/manifest.json
this file does not exist apparently, it locate at http: //my.site.com:8001/__cordova/manifest.json
my question is where send this request?
I fixed it.
All things here is not about nginx, it's about the ROOT_URL of meteor app.
It can work well by setting the ROOT_URL with "http://my.site.com" along with the PORT env when you connect using browser, but if the client is cordova, you have to make your ROOT_URL "http://my.site.com:port"
I use nginx with several fastcgi backends (php-cgi, mod-mono-fastcgi4). Now I need to sent an additional http header to the fastcgi backend, basically the same as proxy_set_header does when using nginx as reverse proxy. But to my findings, there is no such thing as fastcgi_set_header in nginx.
Somebody got any ideas how to do this anyways? I dont want to use additional nginx modules as the solution muste be easily deployable on a wide range of customer systems.
I took a quick look at the manual and I think the closest you will find is passing fastcgi parameters:
The request headers are transferred to the FastCGI-server in the form of parameters. In the applications and the scripts run from the FastCGI-server, these parameters are usually accessible in the form of environment variables. For example, the header "User-agent" is transferred as parameter HTTP_USER_AGENT. Besides the headers of the HTTP request, it is possible to transfer arbitrary parameters with the aid of directive fastcgi_param.
http://wiki.nginx.org/HttpFcgiModule#Parameters.2C_transferred_to_FastCGI-server.
fastcgi_param
syntax: fastcgi_param parameter value
http://wiki.nginx.org/HttpFcgiModule#fastcgi_param
The URLs to the nginx wiki articles above are broken.
nginx exposes request header values via variables prefixed with $http_, so a request header of HTTP_USER_AGENT is available via $http_user_agent.
Likewise a request header named CHICKEN_SOUP would be available via $http_chicken_soup.
The example below shows how to pass the the Authorization HTTP request header to PHP scripts running under php-fpm (PHP FastCGI process manager).
location ~ \.php$ {
fastcgi_pass unix:/path/to/socket;
fastcgi_index index.php;
fastcgi_param HTTP_AUTHORIZATION $http_authorization;
... other settings
}
Nginx now has:
fastcgi_pass_header 'Cache-Control: no-cache, must-revalidate';
Which can be used in your location rules if you are adding headers which aren't already specified in your request. By default fastcgi uses:
fastcgi_pass_request_headers on;
Which will pass all incoming Headers from the request to fastcgi.
You can do this with the third party module ngx_headers_more. After building nginx with this module included, you can do the following in your configuration:
location / {
more_set_input_headers 'Foo: bar baz';
...
}