Ich habe mir den Kopf zerbrochen, um ein 403-Problem zu lösen, das nur mit Chrome zusammenhängt. Ich habe eine Anwendung, die in Tomcat8 läuft, und starte sie mit Nginx. Die Maschine wird bei einem Client gehostet, und ich vermute, dass vielleicht etwas in der Umgebung ist, aber ich brauche etwas, mit dem ich darauf zurückgreifen kann.
Ich kann mich bei der Anwendung anmelden. Ich habe eine Suchseite, die einige JQuery-Ajax-Aufrufe an meine Rest-API ausgibt, mit denen ich die 403 erhalte.
Bei Firefox und IE funktioniert alles gut. Aber bei Chrome und Safari bekomme ich die 403.
Ich dachte, es könnte ein CORS-Problem sein, da ich einen Anruf von Ajax aus tätige. Das Deaktivieren der Websicherheit in Chrome hat nichts bewirkt. Ich bin also nicht überzeugt, dass es daran liegt.
Hier sind meine Konfiguration
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/*;
}
meine 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
}
Hier ist der Nginx-Logeintrag für den 403 bei meinem Serviceaufruf
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"
Der Serviceaufruf im Nginx-Protokoll hat sowohl eine GET- als auch eine POST-Option. Ich kann ein GET an die Adressleiste des Browsers übergeben und es wird funktionieren.
Ich bin ratlos, was das sein könnte. Dies ist eine ziemlich einfache Nginx-Proxy-Konfiguration, die ich mit anderen Clients verwende.
Ich wäre für jede Hilfe sehr dankbar.
Antwort1
Kurz zusammengefasst
Fügen Sie dies dem Serverblock mit der Direktive „proxy_pass“ hinzu
proxy_set_header Origin "";
Verfahren
Ich hatte genau das gleiche Problem und bin beim Googeln auf Ihren Beitrag gestoßen. Nachdem ich die Suche nach einer schnellen Lösung aufgegeben hatte, habe ich Folgendes getan.
Zuerst habe ich überprüft, ob die Anfragen bis zu Tomcat durchgekommen sind. (Ich verwende Docker für Tomcat, daher ist meine Schnittstelle Docker0. Verwenden Sie dies, ifconfig
um herauszufinden, über welche Schnittstelle Ihre Anfragen gehen.)
Dadurch werden die Anfragen in einem eher unfreundlichen Format direkt im Terminal angezeigt
sudo tcpdump -i docker0 -nnSX port 8080
Dadurch wird eine Datei „dump.pcap“ in Ihrem aktuellen Verzeichnis erstellt, die Sie mit Wireshark auf einen Computer kopieren und dort anzeigen können.
sudo tcpdump -i docker0 -w dump.pcap port 8080
Ich sah, dass die Anfragen problemlos ankamen, und es lag an etwas, das Tomcat nicht gefiel, sodass er sie ablehnte, bevor sie überhaupt meinen Java-Code erreichten.
Dann habe ich mithilfe der Entwicklertools von Firefox und Chrome (Strg + Umschalt + i) die tatsächlichen Anfragen überprüft. Gehen Sie zur Registerkarte „Netzwerk“ und suchen Sie nach den fehlgeschlagenen Anfragen. Suchen Sie nach „Anforderungsheadern“ und klicken Sie in Firefox auf „Rohheader“ oder in Chrome auf „Quelltext anzeigen“ und kopieren Sie diese in Notepad++ oder einen anderen Editor, der Zeilen sortieren kann. (Bearbeiten -> Zeilenoperationen -> Zeilen lexikografisch sortieren)
Um zu überprüfen, ob das Problem tatsächlich durch unterschiedliche Header verursacht wurde, habe ich mit Postman beide Header-Sets mit der fehlerhaften URL getestet. In Postman gibt es eine Funktion zur Massenbearbeitung von Headern, mit der Sie Header einfach einfügen können.
Dort musste ich nur noch ausschließen, welcher Header den Fehler verursachte. Zuerst überlegte ich, meinen Javascript-Code so zu ändern, dass Chrome den Origin-Header nicht sendet, dachte aber, es wäre einfacher und zuverlässiger, wenn Nginx die Header entfernt. Ich habe schnell bei Google nach einer Anleitung gesucht und schon war es soweit.
Hoffe, das war hilfreich!
Antwort2
Was bei mir letztendlich funktioniert hat, war das Hinzufügen der Proxy-Direktive proxy_set_header Host $http_host;
Ich habe auch einige Dinge bereinigt, die nicht benötigt wurden. Hier ist die resultierende Konfiguration
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;
}