Score:0

NginX: จะเขียนเนื้อหาและส่วนหัวของการตอบสนองได้อย่างไร

ธง in

บริบท

ฉันมีคอลเล็กชันของหน้า HTML แบบคงที่ (ประมาณ 10,000 หน้า) ที่สร้างโดยแอปพลิเคชันบางตัวซึ่งฉันไม่สามารถควบคุมได้ หน้าเหล่านี้ให้บริการโดย NginX จาก a ที่ตั้ง บล็อก.

เพจอาจมีข้อมูลที่ละเอียดอ่อน ฉันต้องการบล็อกการแสดงเพจตามข้อมูลระบุตัวตนของผู้ใช้และ "แฟล็ก" ในเพจ

แฟล็กเหล่านี้สามารถนำไปใช้ได้โดยก <meta name=keyword content="flag1 flag2 flagn"> ธาตุ. เมื่อมีองค์ประกอบดังกล่าว ควรตรวจสอบ "ข้อมูลประจำตัว"

ความคิดของฉันคือการสแกนการตอบกลับคำขอก่อนที่จะส่งคืนให้กับผู้ใช้ สำหรับสิ่งนี้ฉันต้องการ

  • วิธีส่งการตอบสนองแบบเต็ม (ส่วนหัว + เนื้อหา) ไปยังโค้ดที่กำหนดเองเพื่อให้สามารถแยกวิเคราะห์องค์ประกอบ <head> ได้ หากไม่มีแฟล็ก การตอบกลับจะถูกส่งคืนโดยไม่มีการเปลี่ยนแปลง
    หากมีแฟล็กและผู้ใช้ไม่มีข้อมูลประจำตัว เขาจะถูกขอให้ระบุตัวตน
    หากมีแฟล็กและผู้ใช้มีสิทธิ์ดู การตอบกลับจะถูกส่งกลับโดยไม่มีการเปลี่ยนแปลง
    หากมีแฟล็กและผู้ใช้ไม่มีสิทธิ์เห็น หน้าแสดงข้อผิดพลาดจะถูกส่งกลับแทนการตอบกลับ


    ในที่สุดก็ฟันธง <meta> องค์ประกอบจะถูกลบเพื่อหลีกเลี่ยงการรั่วไหลของคำแนะนำตัวกรอง

  • วิธีที่จะส่งผ่านข้อมูลรหัสผู้ใช้นี้เกี่ยวกับข้อมูลประจำตัวปัจจุบัน (ชื่อผู้ใช้ ค่าทดสอบ ข้อมูลที่เป็นประโยชน์ใดๆ เช่น การประทับเวลาระบุตัวตน â¦)

รหัสผู้ใช้จะขึ้นอยู่กับ "ฐานข้อมูล" (คำนี้ไม่ได้หมายความถึงการใช้เอ็นจิ้น DB จริง) ที่มีสิทธิ์ของผู้ใช้และใช้ฟังก์ชันการหมดเวลา

สามารถใช้รหัสผู้ใช้เป็นสคริปต์ FastCGI ได้หรือไม่ ถ้าเป็นเช่นนั้น อะไรคือคำสั่งให้ส่งคำตอบแบบเต็ม?

การทดลองเบื้องต้น

การระบุผู้ใช้ในปัจจุบันต้องไม่มีเงื่อนไข: เมื่อ auth_basic เปิดใช้งานใน ที่ตั้งผู้ใช้ต้องระบุตัวเอง แม้กระทั่งเพื่อเข้าถึงหน้าสาธารณะ ฉันสามารถลดปัญหานี้ได้ด้วยการมีแขก/ผู้ใช้ทั่วไป/รหัสผ่าน แต่ฉันไม่สามารถมีหน้าคำเตือนก่อนขอข้อมูลรับรองได้

ดังนั้นจึงจำเป็นต้องมีการตรวจสอบสิทธิ์เสมอ หลังจากนั้น อ การอนุญาต: พื้นฐาน some_hash ส่วนหัวถูกส่งไปพร้อมกับคำขอ แฮชนี้จำเป็นต้องถูกจับเมื่อมีการรับรองความถูกต้องสำหรับการเข้าถึงคุณสมบัติสิทธิ์ของผู้ใช้ในอนาคต

ฉันจะทำอย่างไร

ฉันทราบดีว่าในสถานะปัจจุบัน ข้อกำหนดนี้ไม่มีความปลอดภัยที่แท้จริงเลย (เสี่ยงต่อการถูกโจมตีซ้ำ) ฉันต้องการสร้างหลักฐานของแนวคิดก่อนที่จะดำเนินการต่อไป เป้าหมายของฉันสมเหตุสมผลหรือไม่?

มีวิธีจัดการที่ง่ายกว่านี้ไหม? XSLT? (แม้ว่าข้อมูลรับรองผู้ใช้ปัจจุบันจะต้องป้อนในรูปแบบ)

djdomi avatar
za flag
แม้ว่าคำถามจะดี แต่ฉันเชื่อว่ามันไม่เหมาะกับ serverfault.com ฉันคิดว่าเว็บไซต์สำหรับนักพัฒนาที่ฉันไม่คุ้นเคยจะเหมาะกับคุณมากกว่า
Score:1
ธง us

ฉันคิดว่าวิธีเดียวที่จะใช้สิ่งนี้คือใช้ตัวควบคุมส่วนหน้าที่ตรวจสอบข้อกำหนดของลอจิกการเข้าถึง จากนั้นจึงส่งไฟล์ HTML จากดิสก์

คุณจะไม่ใช้ใดๆ รับรองความถูกต้อง คำสั่งจาก nginx กระบวนการรับรองความถูกต้องจะถูกจัดการโดยตัวควบคุมส่วนหน้า

ตัวควบคุมส่วนหน้าสามารถนำไปใช้ได้หลายวิธี เช่น แอปพลิเคชัน Node.JS, PHP, Ruby on Rails และ Python

ajlittoz avatar
in flag
นี่คือสิ่งที่เพื่อนแนะนำ: จัดการคำขอผ่าน "สคริปต์" (Perl, Python, C, â¦) ซึ่งดึงหน้าสแตติก ตัดสินใจว่าจำเป็นต้องใช้ข้อมูลประจำตัวหรือไม่ และส่งคืน "เพจ" (หน้าที่ขอหรือ 401-หน้า). ฉันหวังว่าการส่งคืนรหัส 401 จะเพียงพอที่จะเปิดกล่องโต้ตอบการระบุเบราเซอร์ซึ่งจะส่งส่วนหัว `Authentication:` ส่วนหัวนี้จะใช้เพื่อเก็บข้อมูล "สด" ในเซิร์ฟเวอร์ และส่วนหัว `Authentication:` เพิ่มเติมสามารถละเว้นได้ ทุกอย่างจบลงที่การส่งคุกกี้แบบครั้งเดียวทึบกลับสำหรับคำขอที่ตามมา
us flag
ใช่ นั่นคือแนวทาง และรหัสสถานะ HTTP yesm 401 ทริกเกอร์หน้าต่างการรับรองความถูกต้องในเบราว์เซอร์
ajlittoz avatar
in flag
ฉันทำการทดสอบ: ฉันส่งส่วนหัว `สถานะ: 401 ไม่ได้รับอนุญาต' โดยไม่มีเพย์โหลด (แต่การส่งบล็อก `` ที่สมบูรณ์นั้นไม่มีความแตกต่าง) และสิ่งนี้จะไม่เปิดใช้กล่องโต้ตอบการตรวจสอบสิทธิ์ในเบราว์เซอร์ ฉันควรทำอย่างไร
ajlittoz avatar
in flag
หากต้องการเปิดใช้งานการแจ้งเตือนให้ส่งส่วนหัว `WWW-Authenticate: xxx`
ajlittoz avatar
in flag
แต่ "xxx" ต้องเป็น "พื้นฐาน" จึงจะมีผลและ NginX ขัดขวางการตรวจสอบสิทธิ์อย่างชัดแจ้งเนื่องจากคำขอที่มีส่วนหัว "การรับรองความถูกต้อง:" ไม่เคยเข้ามายังสคริปต์ของฉัน
us flag
คุณต้องแน่ใจว่า nginx ไม่มีคำสั่งการตรวจสอบสิทธิ์ในการกำหนดค่า
ajlittoz avatar
in flag
เนื่องจากขาดรายละเอียดในเอกสารเกี่ยวกับการประมวลผล `WWW-Authenticate:` และการโต้ตอบระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ ฉันจึงพิจารณาที่จะจัดการขั้นตอนการตรวจสอบสิทธิ์นี้ด้วยตนเอง ขณะนี้ฉันกำลังมุ่งเน้นไปที่มาตรการรักษาความปลอดภัยเพื่อป้องกันการโจมตีซ้ำและการสร้างโทเค็นการตรวจสอบสิทธิ์ปลอม ข้อกังวลหลักของฉันคือการออกแบบการแลกเปลี่ยนสำหรับผู้ใช้/รหัสผ่านเดียวกัน ข้อความจะไม่เหมือนกันในความพยายามต่อเนื่องกัน

โพสต์คำตอบ

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