Điểm:2

NGINX chặn quyền truy cập vị trí và chuyển hướng đến trang lỗi tùy chỉnh

lá cờ cn

Tôi gặp sự cố với cài đặt NGINX của mình khi chuyển hướng đến trang lỗi tùy chỉnh ở một vị trí khác (bao gồm css, hình ảnh, js) nếu một trang lỗi bị ném.

Lúc đầu, tôi muốn chặn quyền truy cập vào một thư mục (như .git). Điều này có thể dễ dàng thực hiện thông qua (bên trong khối máy chủ)

vị trí ~ /(.git) {
    Phủ nhận tất cả;
    trả lại 404;
}

Sau đó, tôi đã tạo một phần tử error_page tùy chỉnh (bên trong khối máy chủ) với tệp 404.html tùy chỉnh ở một vị trí khác với thư mục gốc của trang web.

lỗi_trang 404 /404.html;
vị trí = /404.html {
    root /var/data/trang web/trang lỗi;
    nội bộ;
}

Sau những thay đổi này, trang 404 tùy chỉnh của tôi sẽ được hiển thị - nhưng không có css, js và hình ảnh.

Nếu tôi kiểm tra trang web, lý do rất đơn giản: đường dẫn của tệp bị sai - chúng dựa trên vị trí (trong ví dụ của tôi .git). https://it.dmetzler1988.io/.git/css/main.css net::ERR_ABORTED 404.

Đây là tệp cấu hình NGINX hoàn chỉnh cho trang này (chỉ xóa đường dẫn chứng chỉ ssl):

người phục vụ {
    nghe 443 ssl;
    nghe [::]:443 ssl http2;

    ssl_certificate <đường dẫn>;
    ssl_certificate_key <đường dẫn>;

    server_name it.dmetzler1988.io;
    gốc /var/data/websites/dmetzler1988.io/it.dmetzler1988.io;
    chỉ mục index.html index.php;

    lỗi_trang 404 /404.html;
    vị trí = /404.html {
        root /var/data/trang web/trang lỗi;
        nội bộ;
    }

    vị trí ~ /(.git) {
        Phủ nhận tất cả;
        trả lại 404;
    }
}

Vì vậy, câu hỏi của tôi về nơi này:

  1. Làm cách nào để khắc phục sự cố với đường dẫn sai (xóa .git từ đường dẫn)?
  2. Đây có phải là cách chính xác cho trường hợp sử dụng như vậy hay có giải pháp nào tốt hơn không?
lá cờ sv
Chào mừng đến với ServerFault. Tốt nhất là giữ nội dung (main.css, main.js, v.v.) trong một thư mục riêng (chẳng hạn như trong /example-folder/) và sau đó sử dụng một khối vị trí bổ sung (`location /example-folder/ { alias "/ path/to/example-folder"; }`) với tên gốc hoặc bí danh tùy chỉnh để phục vụ các tệp đó.
Ivan Shatsky avatar
lá cờ gr
@PothiKalimuthu Giải pháp của bạn yêu cầu chỉ thị `alias /path/to/example-folder/` để hoạt động chính xác (lưu ý dấu gạch chéo ở cuối).Nếu không có nó, yêu cầu như `/example-folder/css/main.css` sẽ được phục vụ dưới dạng `/path/to/example-foldercss/main.css` rõ ràng sẽ gây ra lỗi `HTTP 404 Not Found`. Tôi đã mô tả hành vi `bí danh` này [tại đây](https://stackoverflow.com/a/69296739/7121513).
devKyrios avatar
lá cờ cn
@IvanShatsky Tôi đã thử nó như bạn mô tả (cũng đã thử nhiều sửa đổi khác nhau) nhưng nó không hoạt động đối với css của tôi (chỉ sử dụng đường dẫn css để kiểm tra). `vị trí ~* /.git/css/.* { root /var/data/websites/error-page/css; }`. Có điều gì sai không? Tôi cũng nhận được lỗi 404 cho tệp này sau khi thêm vị trí mới.
Ivan Shatsky avatar
lá cờ gr
@devKyrios Bạn có thể thêm cấu hình mà bạn đã thử làm bản cập nhật cho câu hỏi của mình không?
devKyrios avatar
lá cờ cn
@IvanShatsky haha, xin lỗi, chỉnh sửa chậm. Hiện đã được thêm vào. Tôi đã thử có và không có `/.*` ở cuối. Ngoài ra với các vị trí phân biệt chữ hoa chữ thường, v.v.
devKyrios avatar
lá cờ cn
@IvanShatsky ôi chết tiệt.. xin lỗi, đừng bận tâm - thất bại của tôi. Nó không hoạt động với khối vị trí mà tôi đã thêm ngày hôm qua ( `location ~ /\.git { return 404; }` ). Tôi có một khối vị trí chồng chéo. Xin lỗi.
Điểm:0
lá cờ gr

Đầu tiên, về các lỗi trong cấu hình của bạn.

vị trí ~ /(.git) {...}

Có vẻ như bạn không quen lắm với các mẫu biểu thức chính quy PCRE. Không cần sử dụng nhóm chụp ở đây - nhóm chụp được sử dụng khi bạn cần nội dung của nó sau này. Tuy nhiên nó không phải là một lỗi nghiêm trọng. Phần tồi tệ nhất là bạn sử dụng dấu chấm không được che chắn, hoạt động như ký tự đại diện trong các mẫu biểu thức chính quy. Bằng cách này, bạn chặn một cách hiệu quả bất kỳ URI nào chứa chuỗi có ký tự thứ hai, thứ ba và thứ tư git (ví dụ. /kích động/index.html, /any/prefix/agitation/index.html, v.v.) Mẫu biểu thức chính quy phù hợp ở đây sẽ là /\.git (chặn mọi thứ bắt đầu bằng .git bao gồm .gitignore, v.v. trên bất kỳ cấp độ thư mục lồng nhau nào).

Tiếp theo, bạn đang sử dụng hai lệnh ở vị trí đó - Phủ nhận tất cảtrả về 404. Chỉ một trong số chúng là đủ ở đây - hoặc Phủ nhận tất cả (trở về HTTP 403 bị cấm) hoặc trả về 404 (trở về Không tìm thấy HTTP 404). Lý do bạn nhận được 404 thay vì 403 là vì trở lại chỉ thị được thực hiện tại VIẾT LẠI giai đoạn xử lý yêu cầu trong khi phủ nhận một thực hiện sau đó QUYỀN giai đoạn (các giai đoạn xử lý yêu cầu được mô tả trong hướng dẫn phát triển).

Bây giờ trở lại câu hỏi của bạn. Có vẻ như bạn đang giới thiệu nội dung của mình bằng đường dẫn URI tương đối, ví dụ:

<link rel="stylesheet" type="text/css" href="css/main.css">

Một số tùy chọn của bạn là (nhưng không giới hạn):

  • nhúng mọi nội dung vào HTML trình xử lý lỗi (bao gồm cả hình ảnh của bạn, bạn có thể mã hóa hình ảnh của mình thành BASE64 và sử dụng URI dữ liệu);

  • di chuyển tất cả nội dung vào một số thư mục trong webroot trang web chính của bạn (giả sử /var/data/websites/dmetzler1988.io/it.dmetzler1988.io/assets/errors và giới thiệu họ bằng đường dẫn đầy đủ:

    <link rel="stylesheet" type="text/css" href="/assets/errors/css/main.css">
    
devKyrios avatar
lá cờ cn
Lúc đầu, cảm ơn bạn rất nhiều vì phản hồi hữu ích của bạn! Kiến thức của tôi về regex trong NGINX có vẻ sai. Ngoài ra, thông tin chỉ thị cũng rất hữu ích - vì vậy tôi chỉ an toàn với chỉ thị `return 404`. Cả hai ý tưởng của bạn để giải quyết vấn đề về nguồn sẽ là một giải pháp, nhưng tôi không muốn sao chép mã và sẽ giữ cho nó dễ dàng chỉnh sửa/có thể hiểu được (không có mã hóa base64 và css/js trong html). Tôi hy vọng rằng có một giải pháp với sửa đổi gốc, proxy hoặc tương tự. Cảm ơn bạn một lần nữa vì những phản hồi rất mang tính xây dựng và hữu ích của bạn!!

Đă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.