1

I've been banging my head trying to figure out a 403 issue only with Chrome. I have a application running in tomcat8 and I front it with Nginx. The machine are hosted with a client and I suspect maybe there is something in the environment, But I need to have something to go back to them with..

I can login to the application. I have a search page that make some jquery ajax call out to me rest api that I get the 403 with..

On Firefox and IE everything works good. But on chrome and safari I get the 403.

I thought it might be a CORS thing since Im making a call from ajax. Disabling web security on Chrome didn't do anything. So im not convinced it is that..

Here are my config

Nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
worker_connections 768;
# multi_accept on;
}

http {

##
# Basic Settings
##

sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;

# server_names_hash_bucket_size 64;
# server_name_in_redirect off;

include /etc/nginx/mime.types;

default_type application/octet-stream;
    include /etc/nginx/proxy_params;
##
# SSL Settings
##

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;

##
# Logging Settings
##

access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;

##
# Gzip Settings
##

gzip on;
gzip_disable "msie6";

# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}

my server.conf

server {
server_name myapp.mydomain.com;
root /var/www/tomcat8/webapps/myapp/;

location / {
index index.html index.jsp;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://127.0.0.1:8080/;
}


}
server {


listen 80;
server_name myapp.mydomain.com;
return 404; # managed by Certbot


}

Here is the nginx log entry for the 403 on my service call

172.16.1.1 - - [19/Jul/2019:16:30:49 -0400] "POST /myap/services/search/lookupUI? HTTP/1.1" 403 0 "https://myapp.mydomain.com/myapp/gui/findpatients.jsp" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36"

The service call in the nginx log has both a GET and POST option..I can pass a GET on the browser address bar and it will work..

I'm pull at straws on what this might be. This is a pretty simple nginx proxy config that I use with other clients..

Any help would be really appreciated.

2 Answers 2

2

TL;DR

Add this to the server block with the proxy_pass directive

proxy_set_header Origin "";

Process

I had this exact same problem and found your post while googling. After giving up finding a quick solution I did the following.

First I checked whether the requests made it through to tomcat. (I use docker for tomcat, so my interface is docker0. Use ifconfig to help figuring out what interface your requests are going through)

This will show the requests in a rather unfriendly format right in the terminal

sudo tcpdump -i docker0 -nnSX port 8080

This will create a file "dump.pcap" in your current directory you can copy to a machine with Wireshark and look at it with that

sudo tcpdump -i docker0 -w dump.pcap port 8080

I saw the requests were coming through fine, and it was something Tomcat didn't like that refused them before they even hit my Java code.

Then using developer tools on both Firefox and Chrome (ctrl - shift - i) I checked the actual requests. Go to the "network" tab and find the failed requests. Look for "Request headers" and click "Raw headers" on Firefox or "View source" on Chrome and copy those into notepad++ or some other editor that can sort lines. (Edit -> Line Operations -> Sort Lines Lexicographically)

To double check that it was indeed the case that difference in headers caused this issue I used Postman to test both sets of headers against the failing URL. There is a bulk edit function in Postman for headers where you can just paste in headers.

There it was just a matter of elimination to figure out which header caused the error. I first considered altering my Javascript code to somehow cause Chrome not to send the Origin header, but figured it was easier and more reliable to have Nginx strip the headers. Did a quick Google search for how to do that, and there you have it.

Hope this was helpful!

2
  • Hey thats for the infor on how to trace the call. I was going to need that if I didn't find the solution.. I did end up with a different solution that I posted Commented Jul 25, 2019 at 13:08
  • I was on a similar journey, here is another interesting thing that I've found: I've raised the logging to the most verbose levels by adding org.apache.catalina.level=FINEST in logging.properties and that gave me org.apache.catalina.filters.CorsFilter.handleInvalidCORS Invalid CORS request; Origin=https://demo.example.com;Method=GET in the catalina.*.log. Anyway the "correct" way would be to configure tomcat, but in the meantime this is a good workaround. Thanks Commented Apr 17 at 22:01
1

What ended up working for me was adding this proxy directive proxy_set_header Host $http_host;

I also cleaned up some stuff that was not needed Here is the resulting config

server {
   server_name myapp.mydomain.com;
   root /var/www/tomcat8/webapps/myapp/;

   location / {
    index index.html index.jsp;
    proxy_set_header Host $http_host;
    proxy_pass http://127.0.0.1:8080/;
   }
   listen 80;

}

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .