Điểm:0

Nginx Reverse Proxy 403 Lỗi trên các yêu cầu POST

lá cờ es

Tôi đang cố gắng thiết lập một nhóm dịch vụ trong Docker: Unifi, PHP, Nginx và Certbot, trong đó Unifi và PHP là các dịch vụ phụ trợ và Nginx phục vụ chúng ở chế độ proxy ngược, trong khi Certbot chạy định kỳ để lấy chứng chỉ SSL cho Nginx .

Tôi có nó chủ yếu là làm việc; tất cả các yêu cầu GET đều hoạt động và tôi có thể xem trang mà Unifi phục vụ. Tuy nhiên, bất kỳ và tất cả các yêu cầu POST qua AJAX đều gây ra lỗi 403 do CORS.

Bây giờ, tôi không rành lắm về cách thao tác với các tiêu đề CORS hoặc nguyên nhân gây ra lỗi. Đó là trình duyệt, Nginx hay unifi? Mặc dù vậy, Nginx là tất cả những gì tôi có thể thay đổi cấu hình.

Đây là lỗi tôi gặp phải đối với tất cả các yêu cầu đăng bài AJAX, từ trình kiểm tra trình duyệt/giám sát mạng:

BƯU KIỆN
sơ đồ https
máy chủ ví dụ.com:8443
tên tệp /api/stat/thiết bị
Địa chỉ (server_ip_address):8443
Trạng thái 403 Bị cấm
Phiên bản HTTP/2
Đã chuyển 141 B (cỡ 0 B)
Chính sách giới thiệu nghiêm ngặt-xuất xứ-khi-xuất xứ chéo
    
    
TIÊU ĐỀ TRẢ LỜI    
độ dài nội dung 0
văn bản kiểu nội dung/đồng bằng
ngày Thứ sáu, 17 tháng 9 năm 2021 00:59:09 GMT
máy chủ nginx
X-Firefox-Spdy h2
    
    
YÊU CẦU TIÊU ĐỀ 
Chấp nhận ứng dụng/json, văn bản/đơn giản, */*
Chấp nhận mã hóa gzip, giảm phát, br
Ngôn ngữ chấp nhận en-US,en;q=0,5
Kết nối duy trì
Độ dài nội dung 0
Cookie hợp nhất=(mã thông báo ngẫu nhiên tại đây); csrf_token=(mã thông báo ngẫu nhiên tại đây)
DNT 1
Ví dụ máy chủ.com:8443
Nguồn gốc https://example.com:8443
Người giới thiệu https://example.com:8443/setup/configure/controller-name
Sec-Fetch-Dest trống
Chế độ tìm nạp giây
Sec-Fetch-Site cùng nguồn gốc
sơ mi rơ moóc
Tác nhân người dùng Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0
X-Csrf-Token (mã thông báo ngẫu nhiên tại đây)

Đây là cấu hình Nginx:

# kích hoạt tính năng nén GZIP
bật gzip;

# mức độ nén (1-9)
# 6 là sự thỏa hiệp tốt giữa việc sử dụng CPU và kích thước tệp
gzip_comp_level 6;

# giới hạn kích thước tệp tối thiểu tính bằng byte để tránh nén âm
gzip_min_length 256;

# nén dữ liệu cho khách hàng kết nối qua proxy
gzip_proxied bất kỳ;

# chỉ đạo các proxy lưu vào bộ đệm cả phiên bản thông thường và GZIp của nội dung
bật gzip_vary;

# tắt tính năng nén GZIP cho các trình duyệt cũ
gzip_disable "msie6";

người phục vụ {
    nghe 80;
    nghe [::]:80;

    server_name example.com;

    vị trí ~ /.well-known/acme-challenge {
        chấp nhận tất cả;
        gốc /var/www/certbot/;
        }
    # Chuyển hướng các đường dẫn Unifi có liên quan Địa chỉ và Cổng Unifi
    địa điểm / {
        viết lại ^ https://$host:8443$request_uri?;
    }
}
người phục vụ {
    nghe 8443 ssl http2;
        nghe [::]:8443 ssl http2;

    server_name example.com;

    server_tokens tắt;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_buffer_size 8k;

    ssl_dhparam /etc/ssl/certs/dhparam-2048.pem;

    ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
    bật ssl_prefer_server_ciphers;

    ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;

    ssl_ecdh_curve secp384r1;
    tắt ssl_session_tickets;

    ssl_bật ghim;
    ssl_stapling_verify bật;
    bộ phân giải 1.1.1.1 1.0.0.1 208.67.222.222 208.67.220.220;


    địa điểm / {

        add_header 'Kiểm soát truy cập-Cho phép-Xuất xứ' '*';
    add_header 'Kiểm soát truy cập-Cho phép-Thông tin xác thực' 'true';
    add_header 'Phương thức kiểm soát truy cập-cho phép' 'NHẬN, ĐĂNG, TÙY CHỌN';
    add_header 'Kiểm soát truy cập-Cho phép-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';



        proxy_pass https://unifi:8443/;
        ủy quyền proxy_set_header "";
        bật proxy_pass_request_headers;
        proxy_set_header Máy chủ lưu trữ $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $remote_addr;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        bật proxy_set_header X-Forwarded-Ssl;
        proxy_http_version 1.1;
        tắt proxy_buffering;
        proxy_redirect tắt;
        proxy_set_header Nâng cấp $http_upgrade;
        proxy_set_header Kết nối "Nâng cấp";
        auth_basic "Hạn chế";
        proxy_set_header Người giới thiệu "";

    }
}

Tôi đã quá mệt mỏi khi tìm kiếm nhiều hướng dẫn bật và tắt Stack Exchange hơn mức tôi có thể theo dõi, đó là lý do tại sao cấu hình của tôi bây giờ quá lộn xộn.

Vì vậy, làm cách nào để tôi sửa đổi Nginx để phục vụ các yêu cầu XHR mà không bị lỗi do CORS?

Chỉnh sửa 1: Tôi đã thêm cổng 443 vào các cổng nghe Nginx cùng với 8443. Nếu tôi truy cập Unifi qua 443 và ủy quyền cho unifi:8443, nó sẽ hoạt động như mong đợi. Nhưng, tôi cần nó hoạt động minh bạch trên 8443.

Chỉnh sửa 2: Tôi đã thử thêm một bộ chứa Nginx "người trung gian" khác với cấu hình được sửa đổi một chút.Tôi đã ủy quyền các yêu cầu tới cổng 8443 trên bộ chứa Nginx ban đầu sang bộ chứa thứ hai trên cổng 443 và ủy quyền ngược lại cho Unifi trên 8443. Kết quả tương tự là không có proxy "man in the middle" như trước đây. Vì vậy, Web -> Nginx trên 8443 -> Nginx trên 443 -> Unfi trên 8443. Đã xóa cấu hình này vì nó không hoạt động, cộng với nó không hiệu quả.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.