ฉันมีปัญหาที่แปลกมากซึ่งฉันไม่สามารถถอดรหัสได้ ฉันกำหนดค่าการแจกจ่าย CloudFront ส่วนตัวเพื่อให้บริการเนื้อหาจากบัคเก็ต S3 ส่วนตัว ฉันใช้คุกกี้ที่ลงชื่อเพื่อให้สิทธิ์การเข้าถึงไฟล์ ฉันยังส่งคำขอข้ามต้นทางจากเบราว์เซอร์สำหรับไฟล์ ดังนั้นฉันจึงต้องอนุญาตให้ใช้ข้อมูลรับรองเพื่อส่งคุกกี้ ฉันกำหนดค่านโยบายส่วนหัวการตอบสนองที่กำหนดเองเพื่อทำสิ่งนี้ (ฉันตั้งค่าให้ตั้งค่า Access-Control-Allow-Credentials เป็นจริง ตั้งค่า Access-Control-Allow-Origin เป็นโดเมนที่ต้องการอย่างชัดเจน และตั้งค่า Access-Control-Allow-Methods / Access-Control-Max-Age อย่างเหมาะสม และตั้งค่าเป็นการแทนที่จากต้นทาง) และฉันยังได้ตั้งค่านโยบายแคชที่กำหนดเองเพื่อแคชตามส่วนหัวของต้นทางและการควบคุมการเข้าถึง
คำสั่ง cURL นี้ไม่ให้การตอบสนองที่ถูกต้อง:
curl -v -H "ที่มา: https://my-subdomain.my-domain.com" -H "คุกกี้: CloudFront-Key-Pair-Id=MyKeyPairID; CloudFront-Policy=Base64EncodedPolicy; CloudFront-Signature=SignedPolicy" https //my-other-subdomain.my-domain.com/key/to/my/private/file.txt
มันให้ผลดังต่อไปนี้:
< HTTP/1.1 200 ตกลง
< ประเภทเนื้อหา: แอปพลิเคชัน/ออคเต็ตสตรีม
< ความยาวเนื้อหา: 576
< การเชื่อมต่อ: รักษาชีวิต
< วันที่: วันศุกร์ที่ 18 กุมภาพันธ์ 2565 18:34:09 น. GMT
< แก้ไขล่าสุด: พฤ. 16 ธ.ค. 2564 14:45:12 น. GMT
< ETag: "a50884915242f9876bea4bb633963191"
< ช่วงที่ยอมรับ: ไบต์
< เซิร์ฟเวอร์: AmazonS3
< แตกต่างกันไป: ต้นทาง, การเข้าถึง-การควบคุม-คำขอ-ส่วนหัว, การเข้าถึง-การควบคุม-คำขอ-เมธอด
< การควบคุมการเข้าถึงอนุญาตแหล่งกำเนิด: https://my-subdomain.my-domain.com
< ต่างกันไป: แหล่งกำเนิด
< X-Cache: เข้าชมจาก cloudfront
< ผ่าน: 1.1 redacted.cloudfront.net (CloudFront)
< X-Amz-Cf-ป๊อป: EWR50-C1
< X-Amz-Cf-Id: JxMbPWHeQr0a9AAlf9PI5ksF6xGKVWL1LvpEC9XEoR_PVuVgiJ5zGA==
< อายุ: 626
สังเกตสิ่งที่หายไป การควบคุมการเข้าถึงอนุญาตข้อมูลประจำตัว หัวข้อ.
อย่างไรก็ตาม คำสั่งนี้ให้การตอบสนองที่ถูกต้อง:
curl -v -H "X-some-header: nonsense" -H "origin: https://my-subdomain.my-domain.com" -H "cookie: CloudFront-Key-Pair-Id=MyKeyPairID; CloudFront- Policy=Base64EncodedPolicy; CloudFront-Signature=SignedPolicy" https://my-other-subdomain.my-domain.com/key/to/my/private/file.txt
ผลตอบแทน:
< HTTP/1.1 200 ตกลง
< ประเภทเนื้อหา: แอปพลิเคชัน/ออคเต็ตสตรีม
< ความยาวเนื้อหา: 576
< การเชื่อมต่อ: รักษาชีวิต
< วันที่: วันศุกร์ที่ 18 กุมภาพันธ์ 2565 18:34:09 น. GMT
< แก้ไขล่าสุด: พฤ. 16 ธ.ค. 2564 14:45:12 น. GMT
< ETag: "a50884915242f9876bea4bb633963191"
< ช่วงที่ยอมรับ: ไบต์
< เซิร์ฟเวอร์: AmazonS3
< แตกต่างกันไป: ต้นทาง, การเข้าถึง-การควบคุม-คำขอ-ส่วนหัว, การเข้าถึง-การควบคุม-คำขอ-เมธอด
< การควบคุมการเข้าถึง-อนุญาต-ข้อมูลประจำตัว: จริง
< การควบคุมการเข้าถึงอนุญาตแหล่งกำเนิด: https://my-subdomain.my-domain.com
< ต่างกันไป: แหล่งกำเนิด
< X-Cache: เข้าชมจาก cloudfront
< ผ่าน: 1.1 redacted.cloudfront.net (CloudFront)
< X-Amz-Cf-ป๊อป: EWR50-C1
< X-Amz-Cf-Id: pUSouCDwLH5Zu6-NBUZqKrb5kY407GLqXXtH4EK2-Th0Z9zZNb54ag==
< อายุ: 693
ในครั้งนี้ด้วยถูกต้อง การควบคุมการเข้าถึงอนุญาตข้อมูลประจำตัว หัวข้อ. ฉันไม่รู้ว่าฉันกำหนดค่าอะไรผิดที่ทำให้เกิดสิ่งนี้หรือทำไมสิ่งนี้ถึงเกิดขึ้นได้ ข้อมูลเชิงลึกใด ๆ จะได้รับการชื่นชมอย่างมาก การกำหนดค่าหรือผลลัพธ์การทดสอบใด ๆ ที่จำเป็น เพียงแจ้งให้เราทราบ
ขอขอบคุณ
แก้ไข:
หลังจากการลองผิดลองถูก ฉันได้พิจารณาแล้วว่าการตั้งค่าการแทนที่ต้นทางในนโยบายส่วนหัวการตอบกลับเป็นสาเหตุของปัญหา เมื่อตั้งค่าเป็น True จะไม่ส่งส่วนหัว Access-Control-Allow-Credentials เว้นแต่คุณจะส่งส่วนหัวที่ไม่เกี่ยวข้องพร้อมกับคำขอของคุณ นี่เป็นปัญหาเนื่องจากทำให้เกิดคำขอ preflight ที่ไม่พึงประสงค์ในเบราว์เซอร์
ปิดการตั้งค่านั้นแล้วกำหนดค่า CORS ของ S3 Bucket ของฉันให้มีลักษณะดังต่อไปนี้แก้ไข:
[
{
"AllowedHeaders": [
"*"
]
"AllowedMethods": [
"รับ",
"ศีรษะ"
]
"AllowedOrigins": [
"https://*",
"http://*"
]
"เปิดเผยส่วนหัว": [
"อีแท็ก"
]
}
]
อย่างไรก็ตาม ฉันยังสงสัยว่าฉันเข้าใจผิดเกี่ยวกับการตั้งค่าการแทนที่ต้นทางหรือไม่ และมีวิธีที่ถูกต้องหรือไม่ หรือนี่เป็นข้อบกพร่องบางอย่างใน CloudFront
แก้ไข 2:
นโยบายคำขอต้นทาง: AWS Managed CORS-S3Oriign (ฉันลองใช้สิ่งนี้และไม่มีนโยบาย ผลลัพธ์เหมือนกัน)
นโยบายแคช: นโยบายที่กำหนดเองเพื่อแคชตามส่วนหัวของ Origin และการควบคุมการเข้าถึง ลองใช้นโยบาย CacheOptimized ที่มีการจัดการมาตรฐานและนโยบาย NoCache เพื่อให้แน่ใจว่าฉันไม่มีปัญหากับคำขอที่ไม่มีข้อมูลประจำตัวที่ติดอยู่ในแคช นอกจากนี้ ลองทำให้แคชใช้ไม่ได้ด้วยตนเองและดูว่าการพบหรือการพลาดสร้างความแตกต่างหรือไม่ ก็ไม่เป็นเช่นนั้น
นโยบายส่วนหัวของการตอบสนอง: กำหนดเองเพื่ออนุญาตข้อมูลประจำตัว นี่คือการกำหนดค่าดั้งเดิม ในที่สุดฉันก็ตั้งค่าการแทนที่ต้นทางเป็นเท็จ และสิ่งต่างๆ ก็เริ่มทำงานถ้าฉันกำหนดค่านโยบาย S3 CORS ใหม่เพื่อตั้งค่าส่วนหัว ฉันมีค่าสุ่มภายใต้ การเข้าถึงการควบคุมอนุญาตส่วนหัว เพราะฉันไม่ได้รับอนุญาตให้เว้นว่างไว้ไม่ว่าจะด้วยเหตุผลใดก็ตาม ส่วนหัวแบบสุ่มที่ส่งไม่จำเป็นต้องตรงกับส่วนหัวที่ตั้งไว้ที่นี่เพื่อรับส่วนหัวข้อมูลประจำตัวที่ส่งคืน แต่ต้องตรงกันเพื่อให้ผ่านการตรวจสอบ preflight ของเบราว์เซอร์ ฉันยังเล่นซอกับการตั้งค่าส่วนหัวที่เปิดเผย ไม่มีอะไรช่วย
หมายเหตุเพิ่มเติม เมื่อ S3 ตั้งค่าส่วนหัว CORS อย่างถูกต้องแล้ว ฉันสามารถลบนโยบายส่วนหัวของการตอบสนองได้ทั้งหมด แต่ฉันต้องคงนโยบายแคชแบบกำหนดเองไว้ มิฉะนั้น ต้นทางที่แตกต่างกันอาจได้รับส่วนหัวที่ไม่ถูกต้อง สิ่งนี้ยังไม่ค่อยเหมาะนัก เนื่องจากฉันจะให้ผู้ใช้เข้าถึงไฟล์เหล่านี้จากต้นทางที่แตกต่างกัน และฉันเชื่อว่าหากนโยบายส่วนหัวของการตอบสนองทำงานได้อย่างถูกต้อง มันจะเป็นการตั้งค่าส่วนหัวหลังจากที่ดึงมาจากแคชแทนที่จะแคชส่วนหัว (แต่ฉัน อาจจะผิดก็ได้) ดูเหมือนว่าตัวเลือกอื่นของฉันคือฟังก์ชัน CF บางตัวที่ทำงานบนการตอบกลับ แต่นั่นทำให้มีค่าใช้จ่ายและค่าใช้จ่ายเพิ่มเติม ในขณะที่นโยบายส่วนหัวการตอบกลับที่ใช้งานได้จะฟรีและมีประสิทธิภาพมากกว่า
แต่สิ่งที่แปลกมากคือแม้ว่า S3 จะตั้งค่าส่วนหัว CORS อย่างถูกต้อง แต่ถ้าฉันใช้นโยบายส่วนหัวการตอบกลับโดยมีการแทนที่ต้นทางจริง ก็ยังหยุดการตอบสนองโดยไม่ได้แนบส่วนหัวแบบสุ่ม
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
