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 !
Related
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
know this has been asked a fair bit but can't find a solution which works for me.
Trying to put an i-frame of our website on a different domain and am getting this error in the browser:
Refused to display 'my-site' in a frame because it set 'X-Frame-Options' to 'sameorigin'.
I have a Passenger server with a Nginx configuration. My site is https and the certificate is from Let's Encrypt Authority X3. It's a ruby on rails app.
I would like to override this setting. I have grep'ed all the files looking for where X-Frame Options has been set but can't find it anywhere - where is it coming from and how can I remove it?
Things i've tried:
I have tried setting add_header X-Frame-Options ALLOWALL always in etc/nginx/sites-enabled - i get the following error in the browser: Refused to display 'my-site' in a frame because it set multiple 'X-Frame-Options' headers with conflicting values ('SAMEORIGIN, ALLOWALL'). Falling back to 'deny'.
I've also tried add_header X-Frame-Options "" always;
I've looked for an SSL config file inside the snippets folder but there doesn't seem to be one.
I was hired to write a wordpress plugin which involves an ajax request to the website's eventespresso api.
I got it working fine locally (calling the live site's api from my local server), but when I activate the plugin on the live site, it throws:
Failed to load http://example.com/wp-json/ee/v4.8.36/events: The
'Access-Control-Allow-Origin' header has a value 'http://opt.local'
that is not equal to the supplied origin. Origin
'http://www.example.com' is therefore not allowed access.
My local domain is "http://opt.local", and the live site is http://example.com.
This error suggests to me that it only wants to allow access from my local setup, and not from the live site, which isn't even cross origin! Maybe I caused it to cache the wrong thing in development?
So a few more tests revealed that the cors settings are correct for everything except the specific route I need.
> curl -I "http://example.com/wp-json"
Access-Control-Allow-Origin: http://example.com
> curl -I "http://example.com/wp-json/ee/v4.8.36"
Access-Control-Allow-Origin: http://example.com
> curl -I "http://example.com/wp-json/ee/v4.8.36/events"
Access-Control-Allow-Origin: http://opt.local
I was able to make it work by using ee/v4.8.35 (a lower api patch version) but hopefully, there is a better solution.
I helped develop the EE4 REST API.
Ya it sounds like some issue where the webserver or a proxy or something is caching the Access-Control-Allow-Origin header.
There's no code in the EE4 REST API that controls that header, that's actually handled by the WP API (on which the EE4 REST API is built).
The relevant code is in wp-includes/rest-api.php in the function rest_send_cors_headers(). That calls get_http_origin(), whose value can be filtered using the filter http_origin.
So you might want to try adding something like
function my_plugin_force_correct_http_origin($http_origin) {
return 'http://example.com';
}
add_filter('http_origin', 'my_plugin_force_correct_http_origin');
that will ensure the PHP code is sending the correct Access-Control-Allow-Origin header.
If that doesn't resolve the issue, I would verify rest_send_cors_headers() is getting called at all (you could temporarily put a line like echo 'called rest_send_cors_headers!';die; inside that function to check).
If it is getting called, and my suggested filter doesn't help, you could try tagging your question with 'wordpress-rest-api'. Also, I would be curious to see if http://example.com/wp-json/ee/v4.8.36/events?limit=50 has the same problem.
Background
So I've got a server running a tomcat application hidden behind an Apache proxy. The proxy provides a more user friendly url as well as SSL encryption with automatic redirects so that the app is only accessible on https.
I'm busy migrating this to an nginx proxy.
One of the issues I've had is that upon login, my app sends back a "LocationAfterLogon" header in the http response in the form of
http://192.168.x.x:8080/myapp/index.jsp.
That IP address returned is from the proxied server not visible on the internet. So then the browser gets a connection error trying to navigate to it.
As a workaround, I've used nginx directives:
proxy_hide_header: to hide the LocationAfterLogin header coming back from the proxied server
add_header: to add a new LocationAfterLogin url.
So my config looks as follows
#header for location after logon of demo app
add_header LocationAfterLogon http://example.com/demo/index.jsp;
#hide the real LocationAfterLogon
proxy_hide_header LocationAfterLogon;
The Problem
I need to be able to do a regex replace or similar on LocationAfterLogon because it won't always be to index.jsp, depending on which url was intercepted by the login page.
I am aware that I can also rewrite the tomcat app to send back a relative URL instead, but I'd like to do it all in nginx config.
I've also read about nginx more_set_headers. Haven't tried it yet. Does it allow me to edit the headers?
Apache has the Header edit directive which I was using previously, so I'm looking for something like that.
TL;DR
Is is possible to edit a header location using regex replace or similar in Nginx?
You can use the map directive to rewrite your header:
map $upstream_http_locationafterlogon $new_location {
~regexp new_value;
}
proxy_hide_header LocationAfterLogon;
add_header LocationAfterLogon $new_location;
See the documentation: http://nginx.org/en/docs/http/ngx_http_map_module.html
I have set up my nginx.conf file to use proxy caching from tutorials I have found online. However, I am trying to figure out how to check if it is actually working. I've read somewhere that adding add_header X-Cache-Status $upstream_cache_status; to the config file in the server section should add a caching header to a response that will show if it was from cache (has values of either a HIT, MISS or EXPIRED). However, I'm wondering WHERE I can actually view this header(and its value) as well as if this is the right way/if there is another way. I'm very new to web in general so sorry if this is a noob question. Thanks!
You have it the right way, to see the headers send back you need to check in your http client. Obviously how to do it, if you can do it, will depend on your client
Here some easy ways to see the headers:
1. curl --head http://your-adress
2. wget --server-response http://your-adress
3. in firefox, install the [liveheaders][1] addon,
go the <url>, rightclick->View page info->headers
4. in opera open dragonfly with ctrl+i
go to network->make request part of the tool,
enter http://your-adress,
the result with headers will be shown in the response field