ข้ามไปยังเนื้อหา

การลงลายเซ็น payload

ทุก payload ที่ FortressFlag ส่งไปยังแอปของคุณมีลายเซ็นติดไปด้วย และทุก SDK ตรวจสอบมันก่อนที่ค่า flag แม้แต่ค่าเดียวจะเปลี่ยน คุณไม่ต้องทำอะไรเลยเพื่อให้ได้สิ่งนี้ — SDK มาพร้อมคีย์สาธารณะของ production ฝังอยู่ในตัว และตรวจสอบโดยค่าเริ่มต้น หน้านี้อธิบายว่ามันให้อะไรกับคุณ การตั้งค่านโยบายสองแบบหมายความว่าอย่างไร และแอปของคุณเชื่อถือคีย์ไหนบ้างในวันนี้

เมื่อแอปของคุณ poll FortressFlag ตอบกลับด้วยสองสิ่ง payload (ค่า flag ของอุปกรณ์ของคุณบน client plane และ ruleset ทั้งชุดบน server plane) และ ลายเซ็น บนไบต์ที่แน่นอนของ payload นั้น ลายเซ็นถูกสร้างด้วยคีย์ส่วนตัวที่มีเพียง FortressFlag เท่านั้นที่ถือ SDK ของคุณตรวจสอบมันด้วยคีย์สาธารณะคู่กันที่มาพร้อมกับ SDK

ถ้าไบต์ถูกเปลี่ยนที่ไหนก็ตามระหว่างเซิร์ฟเวอร์ของเรากับแอปของคุณ — พร็อกซี CDN ไฟล์แคชที่ใครสักคนแก้บนอุปกรณ์ — การตรวจสอบจะล้มเหลวและ SDK จะเพิกเฉยต่อการตอบกลับนั้น มันให้บริการค่าล่าสุดที่มันตรวจสอบแล้วต่อไป (ดูคำสัญญาเรื่อง fallback) แทนที่จะเชื่อไบต์ที่มันรับรองไม่ได้

สองสิ่งที่ลายเซ็น ไม่ ทำ เพื่อจะได้ไม่มีใครพึ่งพามันมากเกินไป

  • มันไม่ซ่อนอะไร payload ไม่ได้ถูกเข้ารหัส — คีย์ไคลเอนต์เป็นสาธารณะโดยการออกแบบ และทุกอย่างที่ให้บริการกับคีย์นั้นก็เช่นกัน อย่าใส่ความลับหรือข้อมูลส่วนบุคคลของผู้ใช้ของคุณลงในกฎ
  • มันไม่แทนที่ TLS SDK คุยกับ FortressFlag ผ่าน HTTPS ด้วยเช่นกัน ลายเซ็นคือกุญแจล็อกชั้นที่สอง สำหรับส่วนของเส้นทางที่ TLS ไม่ครอบคลุม (แคช ที่เก็บข้อมูลบนอุปกรณ์)

ทุก SDK มีนโยบายลายเซ็นที่มีการตั้งค่าสองแบบ

  • required — ค่าเริ่มต้น SDK ตรวจสอบทุก payload กับคีย์ที่มันเชื่อถือ และปฏิเสธทุกอย่างที่ไม่ได้ลงลายเซ็น ลงลายเซ็นด้วยคีย์ที่มันไม่รู้จัก หรือลงลายเซ็นบนไบต์ที่ต่างออกไป นี่คือสิ่งที่คุณต้องการในทุกบิลด์ที่คุยกับ FortressFlag
  • disabled — ยอมรับ payload ที่ไม่ได้ลงลายเซ็น มันมีอยู่เพื่อสถานการณ์เดียว การรันกับแบ็กเอนด์ FortressFlag ในเครื่องที่ไม่ได้ตั้งค่าคีย์ลงลายเซ็นไว้ มันเป็นการตั้งค่าที่มีชื่อและ grep หาได้ ไม่ใช่ fallback แบบเงียบ ๆ ดังนั้น “ทำไมอันนี้ไม่ตรวจสอบ” จึงมีคำตอบอยู่ในซอร์สของคุณเองเสมอ ห้ามปล่อยบิลด์ production พร้อมกับมันเด็ดขาด

ไม่มีโหมด “เตือน” อยู่ตรงกลาง payload จะผ่านการตรวจสอบ หรือไม่ก็ถูกเพิกเฉย

FortressFlag ลงลายเซ็นด้วย หนึ่งคีย์ต่อหนึ่งสภาพแวดล้อม และ SDK มาพร้อมกับความเชื่อถือในคีย์ production เท่านั้น ถ้าคุณทดสอบกับ staging (fortressflag.net) ให้เพิ่มคีย์ staging เข้าไปในคีย์ที่เชื่อถือของ SDK ของคุณอย่างชัดเจน

สภาพแวดล้อม ID ของคีย์ คีย์สาธารณะ (base64url)
Production (fortressflag.com) prod-2026-09-k1 EaEF8MHNu3onHxemTg3-OcrKrq7ODsZIVEp-IVV2ojg
Staging (fortressflag.net) staging-2026-09-k1 RHFhzt8i3hQ4NKv_IrB92YuXmyNfDXx8eWN8cOrEBc8

คีย์เดียวกันในรูปไบต์ดิบแบบเลขฐานสิบหก ถ้าคอนฟิกของคุณรับแบบนั้น

prod-2026-09-k1 11a105f0c1cdbb7a271f17a64e0dfe39cacaaeaece0ec648544a7e215576a238
staging-2026-09-k1 447161cedf22de143834abff22b07dd98b979b235f0d7c7c79637c70eac405cf

แต่ละคีย์เป็นคีย์สาธารณะ Ed25519 ขนาด 32 ไบต์ ID ของคีย์คือส่วนตรงกลางของทุกลายเซ็น (ed25519:prod-2026-09-k1:…) ซึ่งเป็นวิธีที่ SDK รู้ว่าต้องตรวจสอบด้วยคีย์ไหน ค่าเหล่านี้เป็นสาธารณะ — คุณวางมันลงในไฟล์คอนฟิกหรือรีโพซิทอรีได้โดยไม่ต้องคิดซ้ำสอง

เมื่อ FortressFlag หมุนเวียนคีย์ คีย์สาธารณะใหม่จะออกมากับ SDK รุ่นใหม่ก่อน และเราจะเริ่มลงลายเซ็นด้วยมันก็ต่อเมื่อ SDK ที่ใช้งานอยู่ข้างนอกเชื่อถือมันแล้วเท่านั้น การหมุนเวียนไม่มีวันบังคับให้คุณต้องปล่อยแอปภายในกำหนดเวลา SDK ที่เชื่อถือทั้งคีย์เก่าและคีย์ใหม่ตรวจสอบได้ต่อเนื่องตลอด

Web SDK ตรวจสอบด้วย Web Crypto ที่ติดมากับเบราว์เซอร์ของคุณ นั่นต้องการการรองรับ Ed25519 — Safari 17+, Chrome 137+, Firefox 130+ — และ secure context นั่นคือหน้า https:// และ http://localhost บนหน้า http:// ธรรมดาที่ให้บริการจากที่อยู่ LAN เป็นต้น เบราว์เซอร์จะไม่เปิด Web Crypto ให้เลย

ในที่ที่เบราว์เซอร์ตรวจสอบ ไม่ได้ SDK จะไม่แกล้งทำเป็นว่าตรวจสอบแล้ว และไม่ทิ้งแคชที่ดีอยู่แล้วด้วย มันรายงาน payload ว่า ตรวจสอบไม่ได้ ให้บริการค่าล่าสุดที่ตรวจสอบแล้วหรือค่าเริ่มต้นของโค้ดคุณต่อไป และบันทึกเหตุผลลง log หนึ่งครั้ง ให้บริการแอปของคุณผ่าน HTTPS แล้วเรื่องนี้จะไม่เกิดขึ้นเลย