คำอธิบาย

Web Bot Auth สำหรับทีมผลิตภัณฑ์: คำขอจากเอเจนต์ที่ลงลายเซ็นหมายถึงอะไรต่อ roadmap ของคุณ

เอเจนต์ AI และ crawler ต้องการวิธีพิสูจน์ว่าเป็นใครมากขึ้นเรื่อยๆ โดยไม่ต้องพึ่งสตริง User-Agent ที่ใครก็สามารถคัดลอกได้ งานของ IETF ด้าน Web Bot Auth คือความพยายามหลักในการทำให้เรื่องนี้เป็นมาตรฐาน ต่อไปนี้คือคำอธิบายแบบตรงไปตรงมาสำหรับผู้จัดการผลิตภัณฑ์และผู้นำด้านวิศวกรรม: มันทำงานอย่างไร, พิสูจน์อะไรได้, สถานะ ณ เดือนพฤศจิกายน 2026 เป็นอย่างไร, และควรวางแผนอย่างไร

ขอสิทธิ์เข้าถึงก่อนใคร สำรวจวิธีการทำงาน

โดย Toshendra Sharmaผู้ก่อตั้งและ CEO, AgentCredia · Updated November 13, 2026

คำตอบสั้น

Web Bot Auth คือความพยายามของ IETF ที่เปิดทางให้ client อัตโนมัติ รวมถึงเอเจนต์ AI สามารถลงลายเซ็นใน HTTP requests ของตนด้วย HTTP Message Signatures (RFC 9421) และเผยแพร่คีย์เพื่อให้ไซต์ตรวจสอบได้ ลายเซ็นที่ถูกต้องพิสูจน์ได้ว่าคำขอถูกเซ็นโดยคีย์ใด ไม่ได้พิสูจน์ว่าเอเจนต์มีสิทธิ์ดำเนินการได้หรือไม่ ณ เดือนพฤศจิกายน 2026 ข้อกำหนดหลักยังเป็น Internet-Draft ของ working group ดังนั้นทีมผลิตภัณฑ์ควรเตรียมใช้ลายเซ็นเป็นหลักฐานที่แข็งแรง ขณะเดียวกันก็ยังต้องจัดการทราฟฟิกที่ไม่ได้ลงลายเซ็นต่อไป

หลายปีที่ผ่านมา วิธีเดียวที่ client อัตโนมัติจะบอกเว็บไซต์ได้ว่าตัวเองคือใคร คือการใช้ชื่อใน User-Agent header และสำหรับผู้ให้บริการรายใหญ่ไม่กี่ราย ก็อาจมีรายการ IP addresses ที่เผยแพร่ไว้ หรือการตรวจ reverse DNS ชื่อสามารถคัดลอกได้ง่าย รายการเครือข่ายครอบคลุมเฉพาะผู้ให้บริการที่ดูแลรายการของตนเองเท่านั้น เมื่อเอเจนต์ AI เริ่มทำงานแทนผู้ใช้จริงบนเว็บ ช่องว่างนี้จึงกลายเป็นปัญหาของผลิตภัณฑ์ ไม่ใช่แค่ปัญหาด้านความปลอดภัย

Web Bot Auth คือความพยายามหลักในการปิดช่องว่างนั้น มันให้ client อัตโนมัติสามารถลงลายเซ็นในคำขอด้วยคีย์ที่ตนควบคุมและเผยแพร่ไว้ เพื่อให้ไซต์ตรวจสอบลายเซ็นแทนการเชื่อชื่อเอกสารนี้เป็นคำอธิบายสำหรับผู้จัดการผลิตภัณฑ์และผู้นำด้านวิศวกรรมที่ต้องเข้าใจว่ามันคืออะไร, เปลี่ยนอะไร, และไม่เปลี่ยนอะไร โดยไม่ต้องอ่านข้อกำหนดทั้งหมดตั้งแต่ต้นจนจบ

สรุปสั้นๆ

มันคืออะไร: working group ของ IETF, webbotauth, และแนวทางที่กำลังทำให้เป็นมาตรฐานสำหรับการยืนยันตัวตนของ HTTP clients อัตโนมัติ
มันทำงานอย่างไร: client ลงลายเซ็นบางส่วนของแต่ละคำขอโดยใช้ HTTP Message Signatures (RFC 9421) และชี้ไปยังไดเรกทอรีของ public keys ของตน ไซต์ดึงคีย์และตรวจสอบลายเซ็น
มันพิสูจน์อะไร: คีย์ใดเป็นผู้ลงลายเซ็น และส่วนที่ลงลายเซ็นไม่ได้ถูกเปลี่ยนระหว่างทาง
มันไม่พิสูจน์อะไร: ว่าเอเจนต์ได้รับอนุญาตให้ทำตามที่ขอ, ว่ามันทำงานแทนผู้ใช้คนใดคนหนึ่ง, หรือว่ามันจะประพฤติดี
สถานะ ณ เดือนพฤศจิกายน 2026: RFC 9421 เผยแพร่เป็น Proposed Standard แล้ว เอกสารโปรโตคอล Web Bot Auth ยังเป็น Internet-Draft ของ working group ไม่ใช่ RFC
ควรทำอะไร: วางแผนให้ลายเซ็นที่ถูกต้องเป็นหลักฐานที่แข็งแรง, ยังต้องรองรับทราฟฟิกที่ไม่ได้ลงลายเซ็นต่อไป, และเก็บการตัดสินเรื่อง authorization ไว้ในโค้ดของคุณเอง

งานของ IETF ด้าน Web Bot Auth คืออะไร

IETF ได้จัดตั้ง working group Web Bot Auth เพื่อทำให้วิธีการยืนยันตัวตนของ client อัตโนมัติด้วยคริปโตกราฟีเป็นมาตรฐาน และเพื่อให้เว็บไซต์มีข้อมูลเกี่ยวกับผู้ให้บริการที่อยู่เบื้องหลังมากขึ้น charter ของกลุ่มนี้มุ่งไปที่เว็บไซต์ที่ให้บริการมนุษย์เป็นหลัก และระบุ client หลายประเภทไว้ในขอบเขตงาน ได้แก่ crawler, web archive, link checker, AI training crawler และเอเจนต์ AI ที่ทำงานแทนผู้ใช้ปลายทาง

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

charter ระบุผลลัพธ์ที่ต้องส่งมอบไว้สามประเภท:

เอกสาร Standards track เกี่ยวกับเทคนิคการยืนยันตัวตนของ client อัตโนมัติไปยังเว็บไซต์ที่สร้างขึ้นสำหรับผู้คน
เอกสาร Standards track เกี่ยวกับการส่งต่อข้อมูลเพิ่มเติมเกี่ยวกับ bot ที่ร้องขอ โดยใช้ตัวระบุที่มีอยู่แล้ว เช่น domain name หรือ URL
เอกสาร Best current practice หรือ informational เกี่ยวกับหัวข้อด้านการปฏิบัติ เช่น การจัดการคีย์, วงจรชีวิต และการนำไปใช้งาน

สถานะของเอกสาร ณ เดือนพฤศจิกายน 2026

ณ เดือนพฤศจิกายน 2026 working group มีเอกสารที่รับรองแล้วหนึ่งฉบับ: draft-ietf-webbotauth-httpsig-protocol, ชื่อ "HTTP Message Signatures for automated traffic", revision 01 ลงวันที่ 29 ตุลาคม 2026 เอกสารนี้เป็น Internet-Draft ซึ่งหมายความว่ายังอยู่ระหว่างพัฒนาและอาจเปลี่ยนแปลงได้ ยังไม่ใช่ RFC

ยังมี drafts รายบุคคลหลายฉบับที่เกี่ยวข้องกับกลุ่มและกำลังอยู่ระหว่างการหารือ รวมถึงข้อเสนอเกี่ยวกับ registry และรูปแบบ agent card, การยืนยันตัวตนของ bot แบบไม่เปิดเผยชื่อ, รูปแบบ JSON สำหรับเผยแพร่ช่วง IP ของ client อัตโนมัติ, และ header สำหรับ metadata ของเอเจนต์ที่ลงลายเซ็น drafts รายบุคคลเป็นเพียงข้อเสนอ ยังไม่มีฉบับใดถูก adoption โดยกลุ่ม ณ วันที่นี้

charter กำหนด milestones ในช่วงปี 2026 สำหรับส่งข้อกำหนดไปยัง IESG เพื่ออนุมัติ ณ เดือนพฤศจิกายน 2026 เอกสารโปรโตคอลยังคงเป็น draft ของ working group คุณสามารถติดตามสถานะปัจจุบันได้ที่ หน้า IETF datatracker ของ working group และ draft โปรโตคอล

HTTP Message Signatures ทำงานอย่างไร

Web Bot Auth สร้างบน RFC 9421, HTTP Message Signatures ซึ่งเผยแพร่ในเดือนกุมภาพันธ์ 2024 เป็น Proposed Standard RFC 9421 เป็นกลไกทั่วไป: มันกำหนดวิธีลงลายเซ็นในส่วนที่เลือกของ HTTP message และวิธีส่งลายเซ็นผ่าน header Web Bot Auth นำมาปรับใช้กับ client อัตโนมัติ

อธิบายแบบง่ายๆ คำขอจากเอเจนต์ที่ลงลายเซ็นจะทำงานดังนี้:

ผู้ให้บริการสร้าง key pair เก็บ private key ไว้เป็นความลับ และเผยแพร่ public key
client เลือกว่าจะลงลายเซ็นอะไร โดยเลือกองค์ประกอบของคำขอ เช่น target host หรือ URI และเวลาที่สร้าง draft ปัจจุบันกำหนดให้ต้องครอบคลุม authority หรือ target URI ดังนั้นลายเซ็นที่ทำเพื่อไซต์หนึ่งจะนำไปใช้ซ้ำกับอีกไซต์ไม่ได้ง่ายๆ
client ลงลายเซ็นและส่งคำขอ คำขอจะมี header Signature-Input ที่อธิบายว่าส่วนใดถูกลงลายเซ็นและใช้คีย์ใด พร้อมกับ header Signature ที่มีค่าลายเซ็น draft นี้ใช้แท็ก web-bot-auth และคาดว่าจะมีเวลาที่สร้างและเวลาหมดอายุในแต่ละลายเซ็น
ไซต์ตรวจสอบ มันค้นหา public key, สร้างส่วนที่ลงลายเซ็นขึ้นใหม่จากคำขอที่ได้รับ และตรวจสอบลายเซ็น ถ้าการตรวจสอบผ่าน คำขอนั้นก็ถูกลงลายเซ็นโดยผู้ครอบครองคีย์นั้น และส่วนที่ครอบคลุมไม่ได้ถูกแก้ไข

draft ยังเปิดให้ไซต์ร้องขอลายเซ็นได้ด้วย origin สามารถส่ง header Accept-Signature ซึ่งโดยทั่วไปจะมาพร้อมการปฏิเสธ เพื่อบอกว่าต้องการคำขอที่ลงลายเซ็น

แนวคิดเรื่องไดเรกทอรีคีย์

ลายเซ็นจะมีประโยชน์ก็ต่อเมื่อไซต์สามารถหาคีย์สาธารณะที่ถูกต้องได้ Web Bot Auth แก้ปัญหานั้นด้วย key directory

ใน draft ของ working group ปัจจุบัน client จะเพิ่ม header Signature-Agent ที่มี HTTPS URL URL นั้นจะให้บริการไดเรกทอรีของ public keys ของผู้ให้บริการในรูปแบบ JSON Web Key Set ไซต์ดึงไดเรกทอรี, เลือกคีย์ที่ตรงกับ key identifier ในลายเซ็น และตรวจสอบ draft ยังนิยามเส้นทาง well-known ไว้ที่ /.well-known/http-message-signatures-directory ซึ่งผู้ให้บริการสามารถใช้เผยแพร่ไดเรกทอรีของตนได้

แนวคิดที่มีประโยชน์สำหรับทีมผลิตภัณฑ์คือ URL กลายเป็นตัวตน ผู้ให้บริการเอเจนต์ถูกระบุจากตำแหน่งที่เผยแพร่คีย์ ซึ่งทำให้ลายเซ็นผูกกับ domain ที่ผู้ให้บริการควบคุมได้ การหมุนเวียนคีย์ทำได้โดยเผยแพร่คีย์ใหม่ควบคู่กับคีย์เก่า แล้วจึงเอาคีย์เก่าออก

ไซต์ที่ตรวจสอบจำเป็นต้องจัดการไดเรกทอรีอย่างระมัดระวัง: แคชตามกฎ HTTP ปกติ, กำหนดขนาดและ timeout, และหลีกเลี่ยงการดึงจาก private network addresses เหล่านี้เป็นข้อกังวลด้านวิศวกรรมมาตรฐาน และเป็นเหตุผลหนึ่งที่หลายทีมเลือกใช้คอมโพเนนต์ที่ทำการตรวจสอบแทนให้

ลายเซ็นที่ถูกต้องพิสูจน์อะไรได้ และพิสูจน์อะไรไม่ได้

นี่คือส่วนที่สำคัญที่สุดสำหรับทุกคนที่กำลังกำหนดนโยบายผลิตภัณฑ์

ลายเซ็นที่ถูกต้องพิสูจน์ได้ว่า:

คำขอนั้นถูกลงลายเซ็นโดยผู้ครอบครอง private key เฉพาะคีย์หนึ่ง
คีย์นั้นเผยแพร่อยู่ที่ URL ของไดเรกทอรีที่ผู้ให้บริการควบคุมได้
ส่วนที่ลงลายเซ็นในคำขอไม่ได้ถูกเปลี่ยนระหว่างทาง และลายเซ็นยังอยู่ในช่วงเวลาที่ใช้ได้

ลายเซ็นที่ถูกต้องไม่ได้พิสูจน์ว่า:

เอเจนต์นั้น ได้รับอนุญาต ให้ทำการกระทำนั้นได้ การระบุตัวตนไม่ได้เท่ากับการอนุญาต ดู agent authorization
เอเจนต์นั้นทำงานแทนบุคคลใดบุคคลหนึ่งโดยเฉพาะ หรืออยู่ภายใต้อำนาจที่บุคคลนั้นมอบให้ ดู delegated authority
ผู้ให้บริการน่าเชื่อถือหรือเอเจนต์จะประพฤติดี ชื่อเสียงถูกระบุไว้อย่างชัดเจนว่าอยู่นอกขอบเขตของ working group
สิ่งใดๆ เกี่ยวกับคำขอที่ไม่ได้ลงลายเซ็น ทราฟฟิกที่ไม่ได้ลงลายเซ็นยังคงต้องถูกจัดการแยกต่างหาก

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

ทีมผลิตภัณฑ์ควรทำอย่างไรกับเรื่องนี้

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

1. วัดก่อนตัดสินใจ

ดูว่ามีทราฟฟิกอัตโนมัติมากแค่ไหน, เอเจนต์ใช้ route ใด, และส่วนใดถูกลงลายเซ็นบ้าง เริ่มใน observation mode เพื่อให้การวัดไม่เปลี่ยนพฤติกรรมของผู้ใช้

2. แยกหลักฐานออกจากนโยบาย

บันทึกสิ่งที่หลักฐานบอกว่า verified, declared, inferred หรือ unknown แยกจากสิ่งที่คุณตัดสินใจทำ วิธีนี้ทำให้นโยบายอ่านง่าย และช่วยให้คุณเข้มงวดหรือผ่อนคลายได้โดยไม่ต้อง re-instrument evidence basis อธิบายทั้งสี่ระดับ

3. ให้เส้นทางที่ดีกว่าสำหรับเอเจนต์ที่ verified

ถ้ามีเหตุผล ให้ให้เนื้อหาแบบมีโครงสร้างหรือ flow ที่เหมาะกับเอเจนต์กับเอเจนต์ที่ verified แทนหน้าเว็บที่สร้างเพื่อมนุษย์เป็นหลัก คู่มือเกี่ยวกับ การส่งเนื้อหาแบบมีโครงสร้างให้เอเจนต์ AI ครอบคลุมรูปแบบเหล่านี้

4. เก็บการอนุญาตไว้ในโค้ดของคุณ

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

5. วางแผนสำหรับทราฟฟิกที่ไม่ได้ลงลายเซ็นและ Unknown

การรองรับการลงลายเซ็นจะแตกต่างกันไปตามเอเจนต์และเครื่องมือ ดังนั้นควรคาดว่าจะมีทั้งคำขอที่ลงลายเซ็นและไม่ได้ลงลายเซ็นอยู่ระยะหนึ่ง ตัดสินใจแยกตาม route ว่าเกิดอะไรขึ้นกับทราฟฟิกแบบ declared, inferred และ Unknown แทนที่จะใช้กฎเดียวทั้งไซต์ คู่มือเรื่อง การจัดการทราฟฟิก Unknown อธิบายขั้นตอนนี้

Proof of Actor ใช้ Web Bot Auth อย่างไร

Proof of Actor บอกแอปของคุณว่าใครหรืออะไรเป็นผู้กระทำในแต่ละการโต้ตอบ Human, Human + AI, Agent หรือ Unknown และระบุ basis ของหลักฐาน ลายเซ็น Web Bot Auth คือหนึ่งในแหล่งหลักฐานที่แข็งแรงที่สุดของมัน

เมื่อเอเจนต์ลงลายเซ็นในคำขอด้วย HTTP Message Signatures, Proof of Actor จะตรวจสอบลายเซ็นเทียบกับคีย์ที่เผยแพร่ของผู้ให้บริการ ถ้าการตรวจสอบผ่าน ผลลัพธ์จะมี basis แบบ verified พร้อมหลักฐานที่ทีมของคุณสามารถตรวจสอบได้ ถ้า client ระบุตัวเองไว้ใน header เท่านั้น ผลลัพธ์จะเป็น declared ถ้าข้อสรุปอาศัยสัญญาณเชิงพฤติกรรมหรือบริบท ผลลัพธ์จะถูกระบุเป็น inferred ถ้าหลักฐานยังไม่เพียงพอ ผลลัพธ์จะเป็น Unknown

แอปของคุณเป็นผู้ตัดสินใจว่าจะทำอะไรกับบริบทนั้น นโยบายจะเขียนแยกตาม route, ตาม actor class และตาม basis โดยกำหนดผลลัพธ์ได้ เช่น allow, adapt, challenge, review และ rate-limit ไม่มีการบังคับใช้โดยค่าเริ่มต้น: คุณ preview นโยบายกับทราฟฟิกจริง และ enforce ทีละ route ในโค้ดของคุณเอง

ทีม founding สามารถเก็บหลักฐานผ่าน Node.js middleware, Next.js, edge integration, browser collector บนหน้าที่อนุมัติแล้ว, generic HTTP API หรือการเชื่อมต่อกับ MCP server ดู integrations และคู่มือ การตรวจสอบคำขอจากเอเจนต์ที่ลงลายเซ็น สำหรับขั้นตอนเชิงปฏิบัติ

Proof of Actor ยึดขีดจำกัดเดียวกับมาตรฐาน: ลายเซ็นที่ verified บอกได้ว่าคีย์ใดเป็นผู้ลงลายเซ็น ไม่ได้บอกว่าเอเจนต์ได้รับอนุญาตหรือไม่ การอนุญาตยังอยู่ที่คุณ หน้า evidence and limits ระบุชัดเจนว่าแต่ละผลลัพธ์รองรับอะไรได้และรองรับอะไรไม่ได้

เริ่มต้นใช้งาน

Proof of Actor อยู่ใน private beta ทีม founding developer ที่ได้รับคัดเลือกสามารถรับสิทธิ์ใช้งานฟรีได้นานสูงสุด 12 เดือนภายในขอบเขตการใช้งานที่ตกลงกัน โดยไม่มีการเรียกเก็บเงินอัตโนมัติ สมัคร early access และบอกเราว่า route ใดที่คุณคาดว่าเอเจนต์ที่ลงลายเซ็นจะใช้ และคุณอยากทำอะไรกับมัน

สำหรับนักพัฒนา

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent หรือ Unknown
basis: ระดับความแข็งแรงของหลักฐาน: Verified, Declared, Inferred หรือ Unknown
evidence: สัญญาณที่อยู่เบื้องหลังผลลัพธ์ เพื่อให้ทีมของคุณเห็นเหตุผล

เริ่มในโหมด observation: บันทึกผลลัพธ์ไว้ข้าง log ของคุณ และไม่เปลี่ยนแปลงอะไรจนกว่าคุณจะเลือกนโยบาย อ่านคู่มือการเชื่อมต่อ Node.js

คำถามที่พบบ่อย

Web Bot Auth คืออะไร?

Web Bot Auth คือชื่อของ working group ของ IETF คือ webbotauth และเป็นแนวทางที่กำลังทำให้เป็นมาตรฐาน: client อัตโนมัติลงลายเซ็นใน HTTP requests ด้วย HTTP Message Signatures (RFC 9421) และเผยแพร่ public keys ของตน เพื่อให้เว็บไซต์ตรวจสอบได้ว่าผู้ให้บริการรายใดส่งคำขอนั้นมา

Web Bot Auth เป็นมาตรฐานที่เสร็จสมบูรณ์แล้วหรือยัง?

ยังไม่เสร็จ ณ เดือนพฤศจิกายน 2026 เอกสารโปรโตคอลหลัก draft-ietf-webbotauth-httpsig-protocol ยังเป็น Internet-Draft ของ working group ที่ revision 01 RFC 9421 ซึ่งเป็นรูปแบบลายเซ็นที่ใช้เป็นพื้นฐานนั้น ได้เผยแพร่เป็น Proposed Standard แล้ว

ลายเซ็น Web Bot Auth ที่ถูกต้องหมายความว่าเอเจนต์ได้รับอนุญาตให้ทำงานนั้นแล้วหรือไม่?

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

ทีมผลิตภัณฑ์จำเป็นต้อง implement Web Bot Auth เองหรือไม่?

ไซต์เป็นฝ่ายตรวจสอบลายเซ็น ไม่จำเป็นต้องเซ็นอะไรเอง เว้นแต่จะรัน client อัตโนมัติด้วย การตรวจสอบเกี่ยวข้องกับการดึงไดเรกทอรีคีย์, แคชอย่างปลอดภัย และตรวจสอบลายเซ็น ซึ่งเครื่องมืออย่าง Proof of Actor สามารถทำให้คุณได้

เราควรทำอย่างไรกับเอเจนต์ที่ไม่ได้ลงลายเซ็นในคำขอ?

ให้จัดการตามหลักฐานที่มี: declared, inferred หรือ Unknown ควรคาดว่าจะมีทั้งทราฟฟิกที่ลงลายเซ็นและไม่ได้ลงลายเซ็นไปอีกระยะหนึ่ง และกำหนด fallback แยกตาม route แทนที่จะใช้กฎเดียวทั้งไซต์

Proof of Actor ใช้ Web Bot Auth อย่างไร?

มันตรวจสอบ HTTP Message Signatures เทียบกับคีย์ที่เผยแพร่ และเมื่อการตรวจสอบผ่าน ก็จะรายงานผลด้วย basis แบบ verified จากนั้นนโยบายของคุณจึงสามารถปฏิบัติต่อเอเจนต์แบบ verified ต่างจากทราฟฟิกที่เป็น declared หรือ Unknown ได้

รู้ว่าใครกำลังใช้แอปของคุณ

private beta สำหรับกลุ่มเล็กๆ ของ founding developers

ขอสิทธิ์เข้าถึงก่อนใคร ดูราคา

อยากคุยก่อนหรือไม่ พูดคุยกับผู้ก่อตั้ง