ในอดีตอาจมีการใช้คุกกี้ของบุคคลที่สามเพื่อจัดเก็บและสื่อสารข้อมูลเกี่ยวกับสถานะของผู้ใช้ เช่น สถานะการลงชื่อเข้าใช้ ข้อมูลเกี่ยวกับอุปกรณ์ที่ใช้ หรือว่าผู้ใช้รู้จักและเชื่อถือหรือไม่ เช่น ผู้ใช้เข้าสู่ระบบด้วย SSO หรือมีอุปกรณ์ที่เข้ากันได้บางประเภท หรือรู้จักและผู้ใช้เชื่อถือได้หรือไม่ เมื่อเลิกใช้งานการรองรับคุกกี้ของบุคคลที่สามแล้ว การใช้งานส่วนใหญ่เหล่านี้จะได้รับการสนับสนุนด้วยวิธีอื่นๆ
โทเค็นสถานะส่วนตัวเป็นวิธีในการแชร์ข้อมูลทั่วทั้งเว็บ แต่รักษาความเป็นส่วนตัวด้วยการควบคุมปริมาณข้อมูลที่จะแชร์ได้จริง
โทเค็นสถานะส่วนตัว (เดิมเรียกว่า Trust Token) ช่วยให้ระบบถ่ายทอดความไว้วางใจในความจริงของผู้ใช้จากบริบทหนึ่งไปยังอีกบริบทหนึ่งได้ ขณะเดียวกันก็ช่วยเว็บไซต์ต่อสู้กับการประพฤติมิชอบและแยกบ็อตออกจากมนุษย์จริงๆ ได้โดยไม่ต้องมีการติดตามแบบแพสซีฟ
เอกสารนี้สรุปรายละเอียดทางเทคนิคสำหรับการติดตั้งใช้งานโทเค็นสถานะส่วนตัว (PST) สำหรับรายละเอียดเพิ่มเติม โปรดดูภาพรวมของ PST
โทเค็นสถานะส่วนตัวทำงานอย่างไร
ความสัมพันธ์สำคัญที่ต้องทำความเข้าใจใน PST คือระหว่างผู้ออกบัตรและผู้แลกสิทธิ์ ผู้ออกบัตรและผู้แลกสิทธิ์สามารถอยู่ในบริษัทเดียวกัน
- ผู้ออก - เอนทิตีเหล่านี้มีสัญญาณบางอย่างเกี่ยวกับผู้ใช้ (เช่น ผู้ใช้เป็นบ็อตหรือไม่) และฝังสัญญาณนั้นไว้ในโทเค็นที่จัดเก็บไว้ในอุปกรณ์ของผู้ใช้ (รายละเอียดเพิ่มเติมในส่วนถัดไป)
- ผู้แลกสิทธิ์ - เอนทิตีเหล่านี้อาจไม่มีสัญญาณเกี่ยวกับผู้ใช้ แต่จําเป็นต้องรู้บางอย่างเกี่ยวกับผู้ใช้ (เช่น ผู้ใช้นั้นเป็นบ็อตหรือไม่) และขอแลกรับโทเค็นจากผู้ออกบัตรเพื่อทำความเข้าใจความน่าเชื่อถือของผู้ใช้รายนั้น
การโต้ตอบใน PST ทุกครั้งกำหนดให้ผู้ออกบัตรและผู้แลกสิทธิ์ต้องทำงานร่วมกันเพื่อแชร์สัญญาณทั่วทั้งเว็บ สัญญาณเหล่านั้นเป็นค่าคร่าวๆ ซึ่งไม่มีรายละเอียดเพียงพอที่จะระบุถึงตัวบุคคล
โทเค็นสถานะส่วนตัวเหมาะสำหรับฉันหรือไม่
บริษัทที่มีความน่าเชื่อถือและต้องการให้ข้อมูลนั้นเข้าถึงได้ในทุกบริบทอาจได้รับประโยชน์จาก PST สำหรับข้อมูลเพิ่มเติมเกี่ยวกับกรณีการใช้งาน PST ที่อาจเกิดขึ้น โปรดดูเอกสารประกอบเกี่ยวกับกรณีการใช้งาน PST
ออกและแลกโทเค็น
การใช้งาน PST แบ่งเป็น 3 ระยะ ดังนี้
- การออกโทเค็น
- การแลกสิทธิ์โทเค็น
- การส่งต่อบันทึกการแลกใช้
ในระยะแรก จะมีการออกโทเค็นให้กับเบราว์เซอร์ (โดยปกติจะหลังการตรวจสอบบางอย่าง) ในระยะที่ 2 บุคคลอื่นจะส่งคำขอแลกโทเค็นที่ออกเพื่ออ่านค่าในโทเค็นนั้น ในระยะสุดท้าย ผู้ที่แลกสิทธิ์จะได้รับบันทึกการแลกสิทธิ์ (RR) ซึ่งมีมูลค่าอยู่ในโทเค็น จากนั้นฝ่ายที่แลกสิทธิ์ดังกล่าวสามารถใช้บันทึกนั้นเป็นเอกสารรับรองของผู้ใช้ดังกล่าวเพื่อวัตถุประสงค์ต่างๆ
กำหนดกลยุทธ์โทเค็น
ในการกําหนดกลยุทธ์โทเค็น คุณต้องเข้าใจแนวคิดหลักของ PST (โทเค็นและบันทึกการแลกสิทธิ์) ตัวแปร ลักษณะการทํางาน และข้อจํากัดต่างๆ เพื่อให้ทราบถึงการใช้งานที่เป็นไปได้ของกรณีการใช้งานของคุณ
โทเค็นและระเบียนการแลกสิทธิ์: ความสัมพันธ์ระหว่างโทเค็นและการบันทึกอย่างไร
อุปกรณ์แต่ละเครื่องจัดเก็บโทเค็นได้สูงสุด 500 รายการต่อเว็บไซต์และผู้ออกบัตรระดับบนสุด นอกจากนี้ โทเค็นแต่ละรายการจะมีข้อมูลเมตาที่แจ้งว่าคีย์ใดที่ผู้ออกใช้ ซึ่งข้อมูลนี้สามารถใช้ในการตัดสินใจแลกสิทธิ์หรือไม่ใช้โทเค็นในระหว่างขั้นตอนการแลกสิทธิ์ ข้อมูล PST จะถูกเก็บไว้ภายในโดยเบราว์เซอร์ในอุปกรณ์ของผู้ใช้ และสามารถเข้าถึงได้โดย PST API เท่านั้น
เมื่อมีการแลกโทเค็น ระบบจะบันทึกการแลกสิทธิ์ (RR) ไว้ในอุปกรณ์ พื้นที่เก็บข้อมูลนี้ทำหน้าที่เป็นแคชสำหรับการแลกสิทธิ์ในอนาคต จำกัดการแลกสิทธิ์ 2 โทเค็นในทุกๆ 48 ชั่วโมงต่ออุปกรณ์ หน้าเว็บ และผู้ออกบัตร การเรียกใช้การแลกสิทธิ์ใหม่จะใช้ RR ที่แคชไว้หากเป็นไปได้ แทนที่จะส่งคำขอไปยังผู้ออกบัตร
- จะมีการออกโทเค็นใหม่ (สูงสุด 500 รายการต่อผู้ออกบัตร เว็บไซต์ และอุปกรณ์)
- ระบบจะจัดเก็บโทเค็นทั้งหมดไว้ในอุปกรณ์ (คล้ายกับการจัดเก็บคุกกี้)
- หากไม่พบ RR ที่ใช้งานอยู่ ระบบจะสร้าง RR ใหม่ได้หลังจากการออก (สูงสุด 2 รายการทุก 48 ชั่วโมง)
- ระบบจะถือว่า RR ใช้งานได้จนกว่าจะหมดอายุ และใช้เป็นแคชในเครื่อง
- การเรียกใช้การแลกสิทธิ์ใหม่จะเข้าสู่แคชในเครื่อง (ไม่มีการสร้าง RR ใหม่)
หลังจากกำหนด Use Case แล้ว คุณต้องกำหนดอายุการใช้งานของ RR อย่างรอบคอบ เพราะเป็นการกำหนดจำนวนครั้งที่จะใช้ได้ในกรณีของคุณ
คุณควรทำความเข้าใจพฤติกรรมและตัวแปรสำคัญต่อไปนี้ก่อนที่จะกำหนดกลยุทธ์
| ตัวแปร / ลักษณะการทำงาน | คำอธิบาย | การใช้งานที่เป็นไปได้ |
|---|---|---|
| ข้อมูลเมตาของคีย์โทเค็น | โทเค็นแต่ละรายการจะออกได้โดยใช้คีย์การเข้ารหัสเพียงคีย์เดียวเท่านั้น และใน PST จะมีการจำกัดที่ 6 คีย์ต่อผู้ออกใบรับรอง 1 ราย | หนึ่งในวิธีที่เป็นไปได้ในการใช้ตัวแปรนี้คือการกำหนดช่วงความน่าเชื่อถือของโทเค็นตามคีย์การเข้ารหัส (เช่น คีย์ 1 = มีความเชื่อถือสูง ในขณะที่คีย์ 6 = ไม่มีความน่าเชื่อถือ) |
| วันที่หมดอายุของโทเค็น | วันที่หมดอายุของโทเค็นเหมือนกับวันที่หมดอายุของคีย์ | โดยจะมีการหมุนเวียนคีย์อย่างน้อยทุกๆ 60 วัน และจะถือว่าโทเค็นทั้งหมดที่ออกโดยคีย์ที่ไม่ถูกต้องไม่ถูกต้องด้วย |
| ขีดจำกัดอัตราการแลกสิทธิ์โทเค็น | จำกัดการแลกสิทธิ์โทเค็นได้ 2 ครั้งต่ออุปกรณ์และผู้ออกบัตรทุกๆ 48 ชั่วโมง | ขึ้นอยู่กับจำนวนโดยประมาณของการแลกสิทธิ์ที่กรณีการใช้งานของคุณกำหนดไว้ทุกๆ 48 ชั่วโมง |
| จำนวนผู้ออกบัตรสูงสุดต่อต้นทางระดับบนสุด | ปัจจุบันจำนวนผู้ออกบัตรสูงสุดต่อต้นทางระดับบนสุดคือ 2 ราย | กำหนดผู้ออกของแต่ละหน้าอย่างรอบคอบ |
| โทเค็นต่อผู้ออกบัตรบนอุปกรณ์ | ปัจจุบันจำนวนโทเค็นสูงสุดต่อผู้ออกใบรับรองในอุปกรณ์หนึ่งๆ คือ 500 รายการ | โปรดตรวจสอบว่าจำนวนโทเค็นไม่เกิน 500 รายการต่อผู้ออกบัตร อย่าลืมจัดการข้อผิดพลาดในหน้าเว็บเมื่อพยายามออกโทเค็น |
| การหมุนเวียนการคอมมิตคีย์ | ผู้ออก PST ทุกรายจะต้องแสดงปลายทางซึ่งมีสัญญาผูกมัดหลักที่สามารถเปลี่ยนแปลงได้ทุก 60 วันและการหมุนเวียนที่เร็วกว่าที่จะถูกละเว้น | หากคีย์กำลังจะหมดอายุภายในไม่ถึง 60 วัน คุณจำเป็นต้องอัปเดตสัญญาผูกมัดคีย์ก่อนถึงวันดังกล่าวเพื่อหลีกเลี่ยงการหยุดชะงัก (ดูรายละเอียด) |
| ประวัติการแลกสิทธิ์ | คุณกำหนดอายุการใช้งานของ RR เพื่อกำหนดวันที่หมดอายุได้ เนื่องจากมีการแคช RR ไว้เพื่อหลีกเลี่ยงการเรียกใช้การแลกสิทธิ์ครั้งใหม่ที่ไม่จำเป็นไปยังผู้ออกบัตร คุณจึงควรมีสัญญาณการแลกสิทธิ์ที่ใหม่เพียงพอ | เนื่องจากมีการจำกัดอัตราการแลกสิทธิ์ 2 โทเค็นทุกๆ 48 ชั่วโมง คุณจึงต้องกำหนดอายุการใช้งานของ RR เพื่อให้ดำเนินการโทรสำหรับแลกสิทธิ์สำเร็จอย่างน้อยในระยะเวลานี้ (ควรกำหนดอายุการใช้งาน RR ให้สอดคล้องกัน) เราขอแนะนำให้กำหนด อายุการใช้งานตามลำดับของสัปดาห์ |
ตัวอย่างสถานการณ์
สถานการณ์ที่ 1: RR มีอายุการใช้งานน้อยกว่า 24 ชั่วโมง (t=t) และการแลกสิทธิ์จะเกิดขึ้นหลายครั้งในช่วงระยะเวลา 48 ชั่วโมง
สถานการณ์ที่ 2: อายุการใช้งาน RR คือ 24 ชั่วโมง และจะทำการแลกสิทธิ์หลายครั้งในช่วงระยะเวลา 48 ชั่วโมง
สถานการณ์ที่ 3: อายุการใช้งาน RR คือ 48 ชั่วโมง และจะทำการแลกสิทธิ์หลายครั้งในช่วง 48 ชั่วโมง
เรียกใช้การสาธิต
ก่อนที่จะใช้ PST เราขอแนะนำให้ตั้งค่าในเดโมก่อน หากต้องการทดลองใช้การสาธิต PST คุณจะต้องเรียกใช้ Chrome ที่มี Flag เพื่อเปิดใช้สัญญาผูกมัดคีย์ของผู้ออกเดโม (ทำตามวิธีการในหน้าการสาธิต)
การเรียกใช้เดโมนี้แสดงว่าเบราว์เซอร์ของคุณใช้เซิร์ฟเวอร์ผู้ออกเดโมและเซิร์ฟเวอร์ผู้แลกสิทธิ์เพื่อมอบและใช้โทเค็น
ข้อควรพิจารณาด้านเทคนิค
การสาธิตจะทํางานได้ดีที่สุดหากคุณทําตามขั้นตอนต่อไปนี้
- ตรวจสอบว่าคุณได้หยุดอินสแตนซ์ของ Chrome ทั้งหมดก่อนที่จะเรียกใช้ Chrome ที่มีแฟล็ก
- หากคุณกำลังใช้เครื่อง Windows โปรดอ่าน คู่มือนี้เพื่อดูวิธีส่งพารามิเตอร์ไปยังไบนารีปฏิบัติการของ Chrome
- เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ในส่วนแอปพลิเคชัน > พื้นที่เก็บข้อมูล > โทเค็นสถานะส่วนตัวขณะใช้แอปพลิเคชันการสาธิตเพื่อดูโทเค็นที่ออก/แลกสิทธิ์โดยผู้ออกเดโม
ตั้งค่าสำหรับการนำไปใช้งาน
ร่วมเป็นผู้ออกบัตร
ผู้ออกบัตรมีบทบาทสำคัญใน PST โดยจะกำหนดค่าให้กับโทเค็นเพื่อระบุว่าผู้ใช้เป็นบ็อตหรือไม่ หากต้องการเริ่มต้นใช้งาน PST ในฐานะผู้ออก คุณต้องลงทะเบียนโดยทำตามขั้นตอนการลงทะเบียนผู้ออกบัตร
หากต้องการสมัครเป็นผู้ออก โอเปอเรเตอร์ของเว็บไซต์ผู้ออกบัตรต้องเปิดปัญหาใหม่ในที่เก็บ GitHub โดยใช้เทมเพลต "New PST Issuer" ทําตามคําแนะนําในที่เก็บเพื่อกรอกข้อมูลปัญหา เมื่อยืนยันปลายทางแล้ว ระบบจะผสานรวมปลายทางเข้ากับที่เก็บนี้และโครงสร้างพื้นฐานฝั่งเซิร์ฟเวอร์ของ Chrome จะเริ่มดึงข้อมูลคีย์เหล่านั้น
เซิร์ฟเวอร์ผู้ออกบัตร
ผู้ออกบัตรและผู้แลกสิทธิ์คือผู้ดำเนินการสำคัญของ PST โดยมีเซิร์ฟเวอร์และโทเค็นเป็นเครื่องมือหลักสำหรับ PST แม้ว่าเราได้ให้รายละเอียดบางอย่างเกี่ยวกับโทเค็นและในเอกสารประกอบของ GitHub แล้ว แต่เราอยากให้รายละเอียดเพิ่มเติมเกี่ยวกับเซิร์ฟเวอร์ PST หากต้องการตั้งค่าเป็นผู้ออก PST คุณต้องตั้งค่าเซิร์ฟเวอร์ที่ออกไฟล์ก่อน
ทำให้สภาพแวดล้อมใช้งานได้: เซิร์ฟเวอร์ผู้ออก
ในการใช้งานเซิร์ฟเวอร์ผู้ออกโทเค็น คุณจะต้องสร้างแอปพลิเคชันฝั่งเซิร์ฟเวอร์ของคุณเองที่เปิดเผยปลายทาง HTTP
องค์ประกอบของผู้ออกใบรับรองประกอบด้วยโมดูลหลัก 2 โมดูล ได้แก่ (1) เซิร์ฟเวอร์ผู้ออก และ (2) ผู้ออกโทเค็น
เราขอแนะนำให้เพิ่มการปกป้องอีกชั้นหนึ่งให้กับเซิร์ฟเวอร์ผู้ออกบัตร เช่นเดียวกับแอปพลิเคชันที่ใช้งานผ่านเว็บทั้งหมด
เซิร์ฟเวอร์ผู้ออก: ในตัวอย่างของเรา เซิร์ฟเวอร์ที่ออกคือเซิร์ฟเวอร์ Node.js ที่ใช้เฟรมเวิร์ก Express เพื่อโฮสต์ปลายทาง HTTP ของผู้ออก คุณดูโค้ดตัวอย่างใน GitHub ได้
ผู้ออกโทเค็น: คอมโพเนนต์การเข้ารหัสของผู้ออกไม่จำเป็นต้องใช้ภาษาที่เฉพาะเจาะจงใดๆ แต่เนื่องจากข้อกำหนดด้านประสิทธิภาพของคอมโพเนนต์นี้ เราจึงแสดงตัวอย่างการใช้งาน C เป็นตัวอย่าง ซึ่งใช้ไลบรารี Boring SSL เพื่อจัดการโทเค็น คุณดูตัวอย่างโค้ดผู้ออกบัตรและข้อมูลเพิ่มเติมเกี่ยวกับการติดตั้งได้ใน GitHub
คีย์: คอมโพเนนต์ผู้ออกโทเค็นจะใช้คีย์ EC ที่กำหนดเองในการเข้ารหัสโทเค็น คีย์เหล่านี้ต้องได้รับการปกป้องและจัดเก็บไว้ในพื้นที่เก็บข้อมูลที่ปลอดภัย
ข้อกำหนดทางเทคนิคสำหรับเซิร์ฟเวอร์ผู้ออกบัตร
ตามโปรโตคอล คุณจะต้องใช้ปลายทาง HTTP อย่างน้อย 2 รายการในเซิร์ฟเวอร์ผู้ออกบัตร
- สัญญาผูกมัดคีย์ (เช่น
/.well-known/private-state-token/key-commitment): ปลายทางนี้คือที่ที่เบราว์เซอร์จะเข้าถึงรายละเอียดคีย์สาธารณะสำหรับการเข้ารหัสของคุณเพื่อยืนยันว่าเซิร์ฟเวอร์ของคุณถูกต้อง - การออกโทเค็น (เช่น
/.well-known/private-state-token/issuance): ปลายทางการออกโทเค็นที่จะจัดการคำขอโทเค็นทั้งหมด ซึ่งปลายทางนี้จะเป็นจุดผสานรวมสำหรับคอมโพเนนต์ผู้ออกโทเค็น
ดังที่กล่าวไว้ก่อนหน้านี้ เนื่องจากเซิร์ฟเวอร์นี้น่าจะมีการรับส่งข้อมูลจำนวนมาก เราขอแนะนำให้คุณติดตั้งใช้งานด้วยโครงสร้างพื้นฐานที่รองรับการปรับขนาด (เช่น ในสภาพแวดล้อมระบบคลาวด์) เพื่อให้สามารถปรับแบ็กเอนด์ตามความต้องการที่แปรผันได้
ส่งการโทรไปยังเซิร์ฟเวอร์ผู้ออกบัตร
ใช้การเรียกใช้การดึงข้อมูลเว็บไซต์กับสแต็กผู้ออกบัตรเพื่อออกโทเค็นใหม่
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
เซิร์ฟเวอร์ผู้แลกสิทธิ์
คุณจะต้องใช้บริการแลกสิทธิ์โทเค็นด้วยการสร้างแอปพลิเคชันฝั่งเซิร์ฟเวอร์ของคุณเอง ซึ่งจะช่วยให้คุณอ่านโทเค็นที่ผู้ออกบัตรส่งได้ ขั้นตอนต่อไปนี้จะอธิบายวิธีแลกสิทธิ์โทเค็นและวิธีอ่านบันทึกการแลกสิทธิ์ที่เชื่อมโยงกับโทเค็นเหล่านั้น
คุณเลือกเรียกใช้ผู้ออกบัตรและผู้แลกสิทธิ์ในเซิร์ฟเวอร์เดียวกัน (หรือกลุ่มเซิร์ฟเวอร์) ได้
ข้อกำหนดทางเทคนิคสำหรับเซิร์ฟเวอร์ผู้แลกสิทธิ์
ตามโปรโตคอล คุณจะต้องใช้ปลายทาง HTTP อย่างน้อย 2 รายการสำหรับเซิร์ฟเวอร์ผู้แลกสิทธิ์ ดังนี้
/.well-known/private-state-token/redemption: ปลายทางที่จะจัดการการแลกสิทธิ์โทเค็นทั้งหมด ปลายทางนี้จะเป็นที่ที่จะมีการรวม คอมโพเนนต์ตัวปรับปรุงโทเค็น
ส่งการโทรไปยังเซิร์ฟเวอร์ผู้แลกสิทธิ์
หากต้องการแลกสิทธิ์โทเค็น คุณจะต้องใช้การเรียกใช้การดึงข้อมูลเว็บไซต์ไปยังสแต็กผู้แลกสิทธิ์เพื่อแลกสิทธิ์โทเค็นที่ออกให้ก่อนหน้านี้
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
หลังจากแลกโทเค็นแล้ว คุณจะส่งบันทึกการแลกสิทธิ์ (RR) ได้โดยทำการเรียกอีกครั้ง โดยทำดังนี้
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
ติดตั้งใช้งานการติดตั้งใช้งาน
หากต้องการทดสอบการใช้งาน ก่อนอื่นให้ไปที่หน้าเว็บที่มีการเรียกออก แล้วยืนยันว่าสร้างโทเค็นตามตรรกะของคุณ ยืนยันในแบ็กเอนด์ของคุณว่ามีการเรียกตามข้อกำหนด จากนั้นไปยังหน้าเว็บที่โทรติดต่อที่แลกสิทธิ์และตรวจสอบว่ามีการสร้าง RR ตามตรรกะของคุณ
การนำไปใช้งานจริง
เราขอแนะนำให้คุณเลือกเว็บไซต์เป้าหมายที่อยู่ในกรณีการใช้งานของคุณโดยเฉพาะ
- จำนวนการเข้าชมรายเดือนเพียงเล็กน้อย (มีการเข้าชมประมาณ <1 ล้านครั้ง/เดือน): คุณควรเริ่มต้นด้วยการทำให้ API ใช้งานได้กับผู้ชมกลุ่มเล็กๆ ก่อน
- คุณเป็นเจ้าของและควบคุมได้: หากจำเป็น คุณสามารถปิดใช้การติดตั้งใช้งานได้อย่างรวดเร็วโดยไม่ต้องมีการอนุมัติที่ซับซ้อน
- ผู้ออกบัตรไม่เกิน 1 ราย: จำกัดจำนวนโทเค็นเพื่อทำให้การทดสอบง่ายขึ้น
- ไม่เกิน 2 เครื่อง: ให้แก้ปัญหาได้ง่ายขึ้น
การแก้ปัญหา
คุณตรวจสอบ PST ได้จากแท็บเครือข่าย Chrome DevTools และแอปพลิเคชัน
ในแท็บ Network:
ในแท็บแอปพลิเคชัน ให้ทำดังนี้
อ่านเพิ่มเติมเกี่ยวกับการผสานรวมเครื่องมือสำหรับนักพัฒนาเว็บนี้
แนวทางปฏิบัติที่ดีที่สุดและการแก้ปัญหาเกี่ยวกับเซิร์ฟเวอร์
หากต้องการให้เซิร์ฟเวอร์ผู้ออกบัตรและผู้แลกสิทธิ์ทำงานอย่างมีประสิทธิภาพ เราขอแนะนำให้ใช้แนวทางปฏิบัติแนะนำต่อไปนี้เพื่อหลีกเลี่ยงปัญหาเกี่ยวกับการเข้าถึง ความปลอดภัย การบันทึก หรือการรับส่งข้อมูลของ PST
- ปลายทางของคุณต้องใช้การเข้ารหัสที่มีประสิทธิภาพโดยใช้ TLS 1.3 หรือ 1.2
- โครงสร้างพื้นฐานต้องพร้อมรองรับปริมาณการเข้าชมที่ผันแปร (รวมถึงการเพิ่มขึ้นอย่างฉับพลัน)
- ตรวจสอบว่าคีย์ได้รับการป้องกันและรักษาความปลอดภัยโดยสอดคล้องกับนโยบายการควบคุมการเข้าถึง กลยุทธ์การจัดการคีย์ และแผนความต่อเนื่องทางธุรกิจ
- เพิ่มเมตริกความสามารถในการสังเกตลงในสแต็กเพื่อให้แน่ใจว่าคุณจะยังมองเห็นได้เพื่อทำความเข้าใจการใช้งาน จุดคอขวด และปัญหาด้านประสิทธิภาพหลังจากใช้งานจริง
ข้อมูลเพิ่มเติม
- เอกสารตรวจสอบสำหรับนักพัฒนาซอฟต์แวร์
- เริ่มด้วยการอ่านภาพรวมเพื่อทำความเข้าใจความเร็วด้วย PST และความสามารถต่างๆ
- ดูวิดีโอแนะนำ PST
- ลองใช้การสาธิต PST
- นอกจากนี้ ให้อ่านคำอธิบายเกี่ยวกับ API เพื่อทำความเข้าใจรายละเอียดเพิ่มเติมเกี่ยวกับ API นี้ด้วย
- อ่านเพิ่มเติมเกี่ยวกับข้อกำหนดปัจจุบันของ API
- มีส่วนร่วมในการสนทนาผ่านปัญหาเกี่ยวกับ GitHub หรือการโทร W3C
- ดูอภิธานศัพท์ Privacy Sandbox เพื่อทําความเข้าใจคำศัพท์ต่างๆ ให้ดียิ่งขึ้น
- หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับแนวคิดของ Chrome เช่น "ช่วงทดลองใช้จากต้นทาง" หรือ "แฟล็ก Chrome" โปรดดูวิดีโอสั้นๆ และบทความที่มีให้บริการใน goo.gle/cc