Điểm:0

Định cấu hình NGINX để phân phối nội dung JSON khác nhau dựa trên $http_referrer

lá cờ cn

Tôi đang làm việc trên một tổ hợp dịch vụ + webapp + ứng dụng dành cho thiết bị di động

  • ứng dụng di động được sử dụng để tiêu thụ nội dung
  • được tạo bởi một cộng đồng tác giả mở trên ứng dụng web
  • với toàn bộ được phục vụ bởi một máy chủ chạy Nginx trên Ubuntu (một số yêu cầu được ủy quyền cho các máy chủ Nginx phụ trợ) nhưng đó là một chi tiết

Vấn đề mà tôi muốn giải quyết một cách hiệu quả là vấn đề phát sinh từ thực tế là nội dung có thể được tạo bởi một cộng đồng mở - gần như bất kỳ ai cũng có thể nhấp vào một vài nút và bắt đầu quá trình tạo nội dung để máy chủ tạo nội dung sơ khai dưới dạng tệp JSON để tác giả nội dung tùy chỉnh.

Bây giờ, đây là vấn đề - tôi muốn tránh lãng phí thời gian của máy chủ và dung lượng lưu trữ đĩa để tạo nội dung JSON sơ khai cho các tác giả bắt đầu quá trình nhưng không bao giờ thực sự thực hiện trên đó (dịch = đăng ký để tạo nội dung và sau đó không bao giờ thực hiện).

Nói cách khác, tôi chỉ muốn tạo nội dung JSON sơ khai cho các tác giả khi tôi chắc chắn rằng họ thực sự sẽ bắt tay vào quá trình tùy chỉnh nội dung đó. Đồng thời, tôi muốn đảm bảo rằng ứng dụng dành cho thiết bị di động gặp lỗi 404 duyên dáng đối với nội dung do CDN kéo mà ứng dụng này cố gắng lấy qua CDN.

Nói cách khác, có hai nhóm "người tiêu dùng" cho nội dung

  1. Các tác giả nội dung, những người thường sẽ yêu cầu nội dung trực tiếp từ máy chủ của tôi thông qua ứng dụng web hỗ trợ sẽ xuất hiện trên NGINX dưới dạng `$http_reffer = https://example.com/backoffice'
  2. CDN sẽ cố lấy cùng nội dung đó từ cùng một vị trí để đáp ứng các yêu cầu từ ứng dụng dành cho thiết bị di động.

Các phản hồi mặc định cho nội dung bị thiếu là

  1. Tác giả nội dung: Stub JSON được tạo và gửi lại
  2. CDN: Không có tệp JSON nội dung nào tồn tại nên tiêu đề 404 được gửi lại

Giải pháp tôi nghĩ đến là dọc theo khối cấu hình Nginx sau

vị trí/cdn/appdata/nội dung
{
 add_header Access-Control-Allow-Origin *;
 nếu ($http_referer ~* ^https://example.com/backoffice) 
 {
  if (!-e $request_filename) {viết lại ^/(.*)$ /pathto/stub-json-generator.php?$1 cuối cùng;}
 } 
} khác ??? /* phun lại JSON hiện có hoặc trả lời bằng 404. Cả hai đối với người yêu cầu CDN

Thỉnh thoảng tôi tìm hiểu về cấu hình Nginx nhưng không phải là chuyên gia. Câu hỏi của tôi - là những gì tôi đã vạch ra một cách hợp lý để thực hiện nhiệm vụ này hay tôi cần tìm hiểu sâu hơn về Nginx script thông qua JS hoặc Lua? Tập lệnh Lua yêu cầu cài đặt Open Resty, đây là điều tôi muốn tránh vì tôi đã định cấu hình Nginx để hoạt động với Nchan và Dart, điều mà sau đó tôi sẽ phải thực hiện lại tất cả cho Open Resty. Ngoài ra, việc cố gắng truy cập Redis và Postgres từ bên trong tập lệnh Lua sẽ đưa tôi vào một lãnh thổ xa lạ.


Tôi hoàn toàn có thể xóa câu hỏi này nhưng tôi sẽ để nó ở đây với giải pháp của mình vì lợi ích của bất kỳ ai khác muốn làm điều gì đó tương tự.

Trên thực tế, giải pháp rất đơn giản và không hoàn toàn là vấn đề về cấu hình Nginx. Điều quan trọng cần nhận ra là Nginx đang hoạt động trên Ubuntu và hiện có cách phân biệt giữa một thực thư mục và một liên kết tượng trưng. Vì vậy, giả sử chúng tôi đã làm như sau

  • Chỉ định thư mục /đường dẫn/đến/tác giả liên kết tượng trưng /path/to/readercontent do đó
  • ln -s /path/to/authordata /path/to/readercontent

Bây giờ hãy thiết lập các khối cấu hình Nginx sau

vị trí/đường dẫn/đến/dữ liệu tác giả
{
 add_header Access-Control-Allow-Origin *;
 viết lại ^(.*)$ /path/to/authordata/index.php?$1 cuối cùng;
}

 vị trí/đường dẫn/đến/nội dung người đọc
 {
  add_header Access-Control-Allow-Origin *;
 }

Hai khối này không biết nhau thực sự đang giải quyết cùng một thư mục Ubuntu.

Chúng tôi sử dụng cái trước để truy cập dữ liệu tác giả để chỉnh sửa. Vì nội dung được cung cấp bởi tập lệnh PHP nên chúng tôi có khả năng tạo nội dung sơ khai khi đang di chuyển. Bằng cách đó, không có nội dung sơ khai tác giả mặc định không bao giờ được sử dụng làm tắc nghẽn máy chủ.

Chúng tôi sử dụng cái sau để đưa nội dung đọc vào ứng dụng dành cho thiết bị di động thông qua yêu cầu kéo CDN. Tài nguyên dữ liệu tác giả bị thiếu sẽ dẫn đến phản hồi 404 tiêu chuẩn. Tiêu đề CORS, có thể cụ thể hơn, ngăn CDN cố gắng lấy dữ liệu bị trả lại

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