Score:0

การปรับขนาดรูปภาพและการแคชใน NGINX หลังจากการตรวจสอบสิทธิ์และการเปลี่ยนเส้นทาง 302

ธง lr

ฉันมีปัญหากับการปรับขนาดและแคชรูปภาพ นี่คือการตั้งค่าที่ไม่มีประสิทธิภาพของฉันโดยไม่มีการแคช:

  1. ลูกค้าส่งคำขอสำหรับ website.com/static/image.jpeg
  2. เส้นทาง NGINX ไปยัง API
  3. API ตรวจสอบผู้ใช้ สร้าง S3 presigned URL ส่งคืน 302
  4. NGINX จัดการกับการเปลี่ยนเส้นทาง, ปรับขนาดภาพ, ส่งคืนภาพให้กับผู้ใช้, เพิกเฉยต่อ URL ที่กำหนด

ฉันสามารถทำการปรับขนาดแคชได้ทั้งสองแบบ แต่จะมีการสอบถามแคชก่อนการตรวจสอบสิทธิ์ ดังนั้นหากผู้ใช้ 1 รับรองความถูกต้องและผู้ใช้ 2 ที่ไม่ได้ตรวจสอบสิทธิ์ขอเนื้อหาเดียวกันที่มีขนาดเท่ากัน พวกเขาจะได้รับ นี่คือลักษณะที่ปรากฏ (ดู Config 2 ด้านล่าง):

  1. ภาพคำขอของลูกค้า
  2. เซิร์ฟเวอร์ 1 แคช, proxy_passes ไปยังเซิร์ฟเวอร์ 2
  3. เซิร์ฟเวอร์ 2 proxy_passes ไปยัง API
  4. API ตรวจสอบ, สร้าง presigned URL, ส่งคืน 302
  5. เซิร์ฟเวอร์ 2 จัดการการเปลี่ยนเส้นทาง ปรับขนาด และส่งกลับไปยังผู้ใช้

นี่คือสิ่งที่ฉันต้องการทำ แต่ฉันรู้สึกว่าฉันกำลังดิ้นรนกับไวยากรณ์

  1. ภาพคำขอของลูกค้า
  2. เซิร์ฟเวอร์ 1 proxy_passes ไปยัง API
  3. API ตรวจสอบ, สร้าง presigned URL, ส่งคืน 302
  4. เซิร์ฟเวอร์ 1 จัดการการเปลี่ยนเส้นทาง จะแคชการตอบสนองหลังจากปรับขนาด (ใช้คำขอไคลเอนต์เป็นคีย์แคช) เปลี่ยนเส้นทาง/proxy_passes ไปยังเซิร์ฟเวอร์ 2
  5. เซิร์ฟเวอร์ 2 ปรับขนาด

ฉันจะปกป้องทรัพย์สินของฉันอย่างเหมาะสมและปรับขนาด/แคชทรัพย์สินได้อย่างไร

นี่คือการกำหนดค่า 2:

proxy_cache_path /tmp/nginx_cache levels=1:2 keys_zone=nginx_cache:100M max_size=1G ไม่ใช้งาน=40d;

เซิร์ฟเวอร์
{
  ฟัง 80;
  server_name api.example.com;
  ปิด server_tokens;

  สถานที่ /.well-known/acme-challenge/
  {
    รูท /var/www/certbot;
  }

  ที่ตั้ง /
  {
    ส่งคืน 301 https://$host$request_uri;
  }

}

เซิร์ฟเวอร์
{
  ฟัง 443 ssl;
  server_name api.example.com;
  ปิด server_tokens;

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

  รวม /etc/letsencrypt/options-ssl-nginx.conf;
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

  ที่ตั้ง/api
  {
    proxy_pass http://example-api:8080;
    proxy_set_header โฮสต์ $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-ส่งต่อ-สำหรับ $proxy_add_x_forwarded_for;
  }

  ที่ตั้ง /คงที่/
  {
    proxy_pass http://127.0.0.1:10177/;

    proxy_cache nginx_cache;
    proxy_cache_key â$proxy_host$uri$is_args$argsâ;
    proxy_cache_valid 1d;
    หมดอายุ 1d;
  }


}

เซิร์ฟเวอร์
{
  ฟัง 10177;
  server_name s3;

  ที่ตั้ง /
  {
    proxy_connect_timeout 5m;
    proxy_send_timeout 5m;
    proxy_read_timeout 5m;

    client_max_body_size 20M;

    proxy_set_header โฮสต์ $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-ส่งต่อ-สำหรับ $proxy_add_x_forwarded_for;

    proxy_max_temp_file_size 0;

    ปิด proxy_redirect;
    proxy_pass http://example-api:8080/int/static/;

    เปิด proxy_ssl_server_name;

    recursive_error_pages บน;
    เปิด proxy_intercept_errors;

    error_page 301 302 307 = @handle_redirect;

  }

  ## เซิร์ฟเวอร์ API อนุญาตให้ผู้ใช้เข้าถึงสื่อ
  ## เปลี่ยนเส้นทางไปยัง AWS S3 URL ที่กำหนดไว้ล่วงหน้าไปยังสื่อ
  ตำแหน่ง @handle_redirect
  {
    ตัวแก้ไข 8.8.8.8; # เราต้องการ NGINX เพื่อให้สามารถแก้ไข URL ของ AWS ได้

    ตั้ง $saved_redirect_location '$upstream_http_location'; # บันทึกตำแหน่ง URL ที่ API กำลังเปลี่ยนเส้นทางไป
    ตั้ง $saved_request_id '$upstream_http_x_request_id'; # บันทึก ID คำขอที่ส่งคืนจากเซิร์ฟเวอร์ API

    ## แทนที่การหมดเวลาการเชื่อมต่อ
    proxy_connect_timeout 5m;
    proxy_send_timeout 5m;
    proxy_read_timeout 5m;

    ## แทนที่ส่วนหัวคำขอไปยัง AWS ในสิ่งที่ S3 คาดหวัง
    proxy_http_version 1.1;
    การเชื่อมต่อ proxy_set_header "";

    ## ตรวจสอบให้แน่ใจว่าเรากำลังส่งข้อมูลไคลเอนต์ที่ถูกต้องไปยังเซิร์ฟเวอร์ API ไม่ใช่
    ## เซิร์ฟเวอร์ NGINX
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-ส่งต่อ-สำหรับ $proxy_add_x_forwarded_for;

    ## ลบล้างข้อมูลการตรวจสอบสิทธิ์ใดๆ เพื่อให้ AWS สามารถตรวจสอบสิทธิ์จาก URL ที่ลงนามได้
    proxy_set_header การอนุญาต '';

    ## ซ่อนส่วนหัวใดๆ ที่ AWS ส่งคืนจากการส่งคืนกลับไปยังไคลเอ็นต์
    proxy_hide_header x-amz-id-2;
    proxy_hide_header x-amz-meta-...;
    proxy_hide_header x-amz-server-side-encryption;

    ## เราไม่ต้องการให้ AWS ตั้งค่าข้อมูลคุกกี้ใดๆ
    proxy_hide_header Set-Cookie;
    proxy_ignore_headers Set-Cookie;

    ## ตรวจสอบให้แน่ใจว่าได้ยกเลิกการตั้งค่า/ซ่อนคำขอการอนุญาตใดๆ จาก AWS เพื่อให้ไคลเอ็นต์ไม่ได้รับป๊อปอัปที่น่ารำคาญ
    proxy_hide_header WWW-การอนุญาต;
    proxy_hide_header การอนุญาต;

    ## ส่งคำขอไปยัง AWS โดยใช้ URL ที่กำหนด
    proxy_pass $saved_redirect_location;

    ## สกัดกั้นข้อผิดพลาดใดๆ ที่ AWS ส่งกลับ
    เปิด proxy_intercept_errors;
    error_page 301 302 307 = @handle_redirect; # จัดการการเปลี่ยนเส้นทางจาก AWS (เช่น ชื่อโดเมนฝากข้อมูล)

    ตั้ง $ความกว้าง 1024;
    ถ้า ($arg_w ~ /(\d+)/)
    {
      ตั้ง $ความกว้าง $1;
    }
    image_filter ปรับขนาด $ความกว้าง -;
    image_filter_jpeg_quality 75;
    image_filter_buffer 8M;

  }


}

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา