முக்கிய உள்ளடக்கத்திற்கு தவிர்க்கவும்
விளக்கக் குறிப்பு

தயாரிப்பு குழுக்களுக்கான Web Bot Auth: கையொப்பமிட்ட agent கோரிக்கைகள் உங்கள் roadmap-க்கு என்ன அர்த்தம் கொண்டுள்ளன

AI agents மற்றும் crawlers, எவரும் நகலெடுக்கக்கூடிய User-Agent string-ஐ சாராமல், தாங்கள் யார் என்பதை நிரூபிக்க ஒரு வழி அதிகமாக தேவைப்படுகின்றன. IETF Web Bot Auth வேலை இதை தரநிலைப்படுத்தும் முன்னணி முயற்சி. இது product managers மற்றும் engineering leads-க்கு எளிய விளக்கம்: அது எப்படி செயல்படுகிறது, என்ன நிரூபிக்கிறது, 2026 நவம்பர் நிலவரப்படி அதன் நிலை என்ன, மற்றும் அதற்கு எவ்வாறு தயாராக வேண்டும்.

முன்கூட்டிய அணுகலைப் பெறுகஎப்படி செயல்படுகிறது என்பதை ஆராய்க
Toshendra Sharma

ஆசிரியர் Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

பல ஆண்டுகளாக, ஒரு automated client தன்னை ஒரு website-க்கு தெரிவிக்க முடிந்த ஒரே வழி User-Agent header-இல் உள்ள ஒரு பெயர், மேலும் சில பெரிய operators-க்கு மட்டுமே வெளியிடப்பட்ட IP addresses பட்டியல் அல்லது reverse DNS check ஆகியவையாக இருந்தது. பெயர்களை எளிதில் நகலெடுக்கலாம். Network lists அவற்றை பராமரிக்கும் operators-ஐ மட்டுமே உள்ளடக்கும். AI agents இணையம் முழுவதும் உண்மையான மக்களுக்காக செயல்படத் தொடங்கியதால், அந்த இடைவெளி ஒரு product பிரச்சினையாக மாறியுள்ளது, வெறும் security பிரச்சினை மட்டும் அல்ல.

Web Bot Auth அதை மூடுவதற்கான முன்னணி முயற்சி. இது automated clients-க்கு, தாங்கள் கட்டுப்படுத்தும் மற்றும் வெளியிடும் ஒரு key-யுடன் தங்கள் requests-ஐ கையொப்பமிட ஒரு வழியைக் கொடுக்கிறது, அதனால் ஒரு site ஒரு பெயரை நம்புவதற்குப் பதிலாக signature-ஐச் சரிபார்க்க முடியும். இந்த explainer, specifications-ஐ முழுமையாகப் படிக்காமல், அது என்ன, அது என்ன மாற்றுகிறது, என்ன மாற்றவில்லை என்பதைக் grasp செய்ய வேண்டிய product managers மற்றும் engineering leads-க்காக எழுதப்பட்டுள்ளது.

சுருக்கமான பதிப்பு

  • இது என்ன: automated HTTP clients-ஐ authenticate செய்வதற்காக IETF working group, webbotauth, மற்றும் அது தரநிலைப்படுத்தும் அணுகுமுறை.
  • இது எப்படி செயல்படுகிறது: client, HTTP Message Signatures (RFC 9421) மூலம் ஒவ்வொரு request-இலும் சில பகுதிகளை கையொப்பமிடுகிறது, மேலும் தனது public keys அடங்கிய directory-ஐ சுட்டிக்காட்டுகிறது. site key-ஐ fetch செய்து signature-ஐ verify செய்கிறது.
  • இது என்ன நிரூபிக்கிறது: எந்த key request-ஐ கையொப்பமிட்டது, மேலும் transit-இல் signed பகுதிகள் மாற்றப்படவில்லை என்பதையும்.
  • இது என்ன நிரூபிக்கவில்லை: அந்த agent கேட்பதைச் செய்ய அனுமதி பெற்றுள்ளது, அது ஒரு குறிப்பிட்ட user-க்காக செயல்படுகிறது, அல்லது அது நன்றாக நடந்து கொள்ளும் என்பதையும்.
  • 2026 நவம்பர் நிலவரப்படி நிலை: RFC 9421 வெளியிடப்பட்ட Proposed Standard ஆகும். Web Bot Auth protocol document ஒரு working group Internet-Draft; இன்னும் RFC அல்ல.
  • என்ன செய்ய வேண்டும்: செல்லுபடியாகும் signatures-ஐ வலுவான evidence ஆக கருதத் திட்டமிடுங்கள், unsigned traffic-ஐ கையாளுவதைத் தொடருங்கள், மற்றும் authorization முடிவுகளை உங்கள் own code-இல் வைத்திருங்கள்.

IETF Web Bot Auth வேலை என்ன

IETF, automated clients-ஐ cryptographically authenticate செய்யும் முறைகளையும், அவற்றின் பின்னால் உள்ள operators பற்றி websites-க்கு கூடுதல் தகவலை வழங்கும் முறைகளையும் தரநிலைப்படுத்த Web Bot Auth working group-ஐ charter செய்தது. இந்த charter, முதன்மையாக மக்களுக்கு சேவை செய்யும் sites-ஐ கவனம் செலுத்துகிறது, மேலும் scope-இல் உள்ள clients-க்கு ஒரு பரந்த வரம்பை குறிப்பிடுகிறது: crawlers, web archivers, link checkers, AI training crawlers, மற்றும் end users-க்காக செயல்படும் AI agents.

Charter-இல் குறிப்பிடப்பட்ட இரண்டு விலக்குகள் product teams-க்கு கவனிக்கத்தக்கவை. End-user authentication scope-இல் இல்லை, ஆகவே இது ஒரு நபரை log in செய்யும் வழி அல்ல. Bot reputation tracking-மும் scope-இல் இல்லை, ஆகவே standard ஒரு request-ஐ யார் கையொப்பமிட்டது என்பதைச் சொல்கிறது, அந்த operator நம்பகமானவரா என்பதை அல்ல.

Charter மூன்று வகை deliverables-ஐ பட்டியலிடுகிறது:

  1. மக்களுக்காக உருவாக்கப்பட்ட websites-க்கு automated clients-ஐ authenticate செய்யும் நுட்பங்களைப் பற்றிய Standards track documents.
  2. domain name அல்லது URL போன்ற ஏற்கனவே உள்ள identifier-ஐப் பயன்படுத்தி, கோரிக்கை விடுக்கும் bot பற்றி கூடுதல் தகவலை வழங்கும் Standards track documents.
  3. key management, lifecycle, மற்றும் deployment போன்ற operational topics-இல் Best current practice அல்லது informational documents.

2026 நவம்பர் நிலவரப்படி documents-ன் நிலை

2026 நவம்பர் நிலவரப்படி, working group-க்கு ஒரு adopted working group document உள்ளது: draft-ietf-webbotauth-httpsig-protocol, தலைப்பு "HTTP Message Signatures for automated traffic", revision 01, தேதி October 29, 2026. இது ஒரு Internet-Draft, அதாவது இன்னும் மாறக்கூடிய work in progress. இது RFC அல்ல.

பல individual drafts-களும் குழுவுடன் தொடர்புபடுத்தப்பட்டு விவாதத்தில் உள்ளன, அதில் registry மற்றும் agent card format, anonymous bot authentication, automated clients-ன் IP ranges-ஐ வெளியிட JSON format, மற்றும் signed agent metadata-க்கான header பற்றிய முன்மொழிவுகள் அடங்கும். Individual drafts என்பது proposals; இந்த தேதியளவில் அவற்றில் எதுவும் குழுவால் adopt செய்யப்படவில்லை.

Charter, specifications-ஐ approval க்காக IESG-க்கு அனுப்ப 2026-இல் milestones-ஐ நிர்ணயித்தது. 2026 நவம்பர் நிலவரப்படி, protocol document இன்னும் working group draft ஆகவே உள்ளது. தற்போதைய நிலையை IETF datatracker page for the working group மற்றும் protocol draft-இல் பின்தொடரலாம்.

HTTP Message Signatures எப்படி செயல்படுகின்றன

Web Bot Auth, RFC 9421, HTTP Message Signatures-ஐ அடிப்படையாகக் கொண்டது; இது February 2024-இல் Proposed Standard ஆக வெளியிடப்பட்டது. RFC 9421 ஒரு பொதுவான mechanism: இது HTTP message-இன் தேர்ந்தெடுக்கப்பட்ட பகுதிகளை எப்படி கையொப்பமிடுவது, signature-ஐ headers-இல் எப்படி எடுத்துச் செல்லுவது என்பதை வரையறுக்கிறது. Web Bot Auth அதை automated clients-க்காக profile செய்கிறது.

எளிய சொற்களில், கையொப்பமிடப்பட்ட agent request இப்படிச் செயல்படுகிறது:

  1. Operator ஒரு key pair-ஐ உருவாக்குகிறது. அது private key-ஐ ரகசியமாக வைத்துக் கொண்டு public key-ஐ வெளியிடுகிறது.
  2. Client என்ன கையொப்பமிட வேண்டும் என்பதைத் தேர்வு செய்கிறது. அது request-இன் components-ஐ, உதாரணமாக target host அல்லது URI மற்றும் ஒரு creation time-ஐ தேர்வுசெய்கிறது. தற்போதைய draft, authority அல்லது target URI-யை கவரேஜில் வைத்திருக்க வேண்டும் எனக் கோருகிறது, ஆகவே ஒரு site-க்கான signature-ஐ மற்றொரு site-க்கு எளிதில் replay செய்ய முடியாது.
  3. Client கையொப்பமிட்டு அனுப்புகிறது. Request ஒரு Signature-Input header-ஐ எடுத்துச் செல்கிறது, அதில் என்ன கையொப்பமிடப்பட்டது, எந்த key-யால் என்பது விவரிக்கப்படுகிறது, மற்றும் signature value கொண்ட ஒரு Signature header-ஐ கொண்டுள்ளது. Draft ஒரு web-bot-auth tag-ஐ பயன்படுத்துகிறது, மேலும் ஒவ்வொரு signature-க்கும் creation மற்றும் expiry times-ஐ எதிர்பார்க்கிறது.
  4. Site சரிபார்க்கிறது. அது public key-ஐ கண்டுபிடித்து, பெற்ற request-இலிருந்து signed components-ஐ மீண்டும் உருவாக்கி, signature-ஐச் சரிபார்க்கிறது. Check pass ஆனால், request அந்த key-யை வைத்திருப்பவரால் கையொப்பமிடப்பட்டது, மேலும் covered பகுதிகள் மாற்றப்படவில்லை.

Draft, site-ஐ signature கேட்கவும் அனுமதிக்கிறது. Origin ஒரு Accept-Signature header-ஐ, பொதுவாக refusal-உடன், அனுப்பி signed requests-ஐ விரும்புகிறது என்பதை signal செய்யலாம்.

Key directory யோசனை

Signature-க்கு site சரியான public key-ஐ கண்டுபிடிக்க முடிந்தால் மட்டுமே அது பயனுள்ளது. Web Bot Auth அதற்கு ஒரு key directory மூலம் பதிலளிக்கிறது.

தற்போதைய working group draft-இல், client ஒரு HTTPS URL-ஐ உள்ளடக்கிய Signature-Agent header-ஐ சேர்க்கிறது. அந்த URL, operator-ன் public keys-ன் directory-யை JSON Web Key Set ஆக வழங்குகிறது. Site அந்த directory-யை fetch செய்து, signature-இல் உள்ள key identifier-க்கு பொருந்தும் key-யைத் தேர்வு செய்து verify செய்கிறது. Draft /.well-known/http-message-signatures-directory எனும் well-known path-ஐயும் வரையறுக்கிறது, அங்கு operator தன் directory-ஐ சேவையிடலாம்.

Product teams-க்கு இதிலுள்ள பயனுள்ள கருத்து: URL identity ஆக மாறுகிறது. Agent operator தனது keys-ஐ எங்கு வெளியிடுகிறதோ, அதனால் அது கட்டுப்படுத்தும் domain-உடன் signature இணைகிறது. Key rotation, பழைய key-யுடன் புதிய key-ஐ வெளியிட்டு, பின்னர் பழைய key-ஐ நீக்குவதன் மூலம் செயல்படுகிறது.

Verifying sites directories-ஐ கவனமாகக் கையாள வேண்டும்: சாதாரண HTTP rules-ஐப் பின்பற்றி அவற்றை cache செய்யுங்கள், அளவு வரம்புகளும் timeout-களும் அமைக்குங்கள், மேலும் private network addresses-இல் இருந்து fetch செய்வதைத் தவிர்க்குங்கள். இவை வழக்கமான engineering concerns, மேலும் பல teams தங்களுக்கு verification செய்யும் ஒரு component-ஐ விரும்புவதற்கான காரணங்களிலும் இதுவும் ஒன்று.

செல்லுபடியாகும் signature என்ன நிரூபிக்கிறது, என்ன நிரூபிக்கவில்லை

இது product policy எழுதுபவர்களுக்கான மிக முக்கியமான பகுதி.

செல்லுபடியாகும் signature நிரூபிப்பது:

  • Request ஒரு குறிப்பிட்ட private key-யை வைத்திருப்பவரால் கையொப்பமிடப்பட்டது.
  • அந்த key, operator கட்டுப்படுத்தும் directory URL-இல் வெளியிடப்பட்டுள்ளது.
  • Request-இன் கையொப்பமிடப்பட்ட பகுதிகள் transit-இல் மாற்றப்படவில்லை, மேலும் signature அதன் validity window-க்குள் உள்ளது.

செல்லுபடியாகும் signature நிரூபிக்காதது:

  • அந்த agent செய்யும் action-க்கு அனுமதி பெற்றது என்பதை. அடையாளம் காணக்கூடியது என்பது permission அல்ல. agent authorization-ஐப் பார்க்கவும்.
  • அந்த agent ஒரு குறிப்பிட்ட நபருக்காக, அல்லது அந்த நபர் அதற்கு அளித்த authority-க்குள் செயல்படுகிறது என்பதை. delegated authority-ஐப் பார்க்கவும்.
  • Operator நம்பகமானவர் அல்லது agent நன்றாக நடக்கும் என்பதை. Reputation working group-இன் scope-இல் வெளிப்படையாக இல்லை.
  • Signed அல்லாத requests பற்றி எதையும். Unsigned traffic-க்கும் தனித்தனி கையாளுதல் தேவை.

செல்லுபடியாகும் signature-ஐ request-ஐ யார் அனுப்பினார் என்பதற்கான வலுவான evidence ஆகக் கருதுங்கள், பின்னர் உங்கள் own access control அந்த sender என்ன செய்யலாம் என்பதை தீர்மானிக்கட்டும்.

Product teams இதைப் பற்றி என்ன செய்ய வேண்டும்

ஒரு RFC-ஐக் காத்திருக்க வேண்டியதில்லை. Signed agent traffic நீங்கள் இப்போதே தயாராகக் கொள்ளக்கூடிய ஒன்று, draft-இன் சில விவரங்கள் மாறக்கூடும் என்ற எதிர்பார்ப்புடன்.

1. முடிவு செய்வதற்கு முன் அளவிடுங்கள்

உங்கள் traffic-இல் எவ்வளவு automated, agents எந்த routes-ஐ பயன்படுத்துகின்றன, மற்றும் அதில் எவ்வளவு signed என்பதை அறிந்துகொள்ளுங்கள். observation mode-இல் தொடங்குங்கள், அதனால் அளவிடுவது உங்கள் users-க்கு எதையும் மாற்றாது.

2. Evidence-ஐ policy-இலிருந்து பிரிக்கவும்

Evidence என்ன சொல்கிறது என்பதை, verified, declared, inferred அல்லது unknown, நீங்கள் என்ன செய்ய முடிவு செய்கிறீர்கள் என்பதிலிருந்து தனியாக பதிவு செய்யுங்கள். அது policies-ஐ வாசிக்க எளிதாக்கும், மேலும் மீண்டும் instrumentation செய்யாமல் அவற்றை கடுமையாக்கவும் அல்லது தளர்த்தவும் உதவும். evidence basis entry நான்கு நிலைகளையும் விளக்குகிறது.

3. Verified agents-க்கு சிறந்த வழி கொடுக்கவும்

அர்த்தமுள்ளதாக இருக்கும் இடங்களில், verified agents-க்கு மக்களுக்காக உருவாக்கப்பட்ட pages-க்கு பதிலாக structured content அல்லது agent-friendly flow-ஐ வழங்குங்கள். serving AI agents structured content குறித்த guide patterns-ஐ விளக்குகிறது.

4. Authorization-ஐ உங்கள் code-இல் வைத்திருங்கள்

Signature-ஐ, யார் கேட்கிறார்கள் என்பதை அறியப் பயன்படுத்துங்கள். உங்கள் தற்போதைய permissions, scopes மற்றும் confirmations-ஐ, அவர்கள் என்ன செய்யலாம் என்பதைத் தீர்மானிக்கப் பயன்படுத்துங்கள். உயர்ந்த தாக்கம் கொண்ட actions-க்கு இன்னும் மனிதர் மூலம் confirmation தேவைப்படலாம், அந்த request-ஐ யார் கையொப்பமிட்டிருந்தாலும். protecting sensitive actions without blocking agents-ஐப் பார்க்கவும்.

5. Unsigned மற்றும் Unknown traffic-ஐ திட்டமிடுங்கள்

Signing support agents மற்றும் tools-இல் மாறுபடுகிறது, ஆகவே சில காலம் signed மற்றும் unsigned requests கலவையை எதிர்பாருங்கள். ஒரே site-wide rule-ஐத் தேர்வு செய்வதைவிட, ஒவ்வொரு route-க்கும் declared, inferred மற்றும் Unknown traffic-க்கு என்ன நடக்க வேண்டும் என்பதை முடிவு செய்யுங்கள். handling Unknown traffic குறித்த guide இதை வழிநடத்துகிறது.

Proof of Actor Web Bot Auth-ஐ எப்படி பயன்படுத்துகிறது

Proof of Actor உங்கள் application-இல் ஒவ்வொரு interaction-இலும் யார் அல்லது எது செயல்படுகிறது என்பதை தெரிவிக்கிறது, Human, Human + AI, Agent அல்லது Unknown, மேலும் evidence basis-ஐ குறிப்பிடுகிறது. Web Bot Auth signatures அதன் மிக வலுவான evidence மூலங்களில் ஒன்றாகும்.

ஒரு agent தன் request-ஐ HTTP Message Signatures மூலம் கையொப்பமிடும்போது, Proof of Actor அந்த signature-ஐ operator-ன் வெளியிடப்பட்ட key-க்கு எதிராகச் சரிபார்க்கிறது. Check pass ஆனால், முடிவு ஒரு verified basis-உடன், உங்கள் team பரிசீலிக்கக்கூடிய evidence-உடன் வருகிறது. ஒரு client header-இல் தன்னை மட்டும் பெயரிட்டால், முடிவு declared. Conclusion நடத்தை அல்லது context signals-ஐ அடிப்படையாகக் கொண்டால், அது inferred என குறிக்கப்படுகிறது. Evidence போதுமானதாக இல்லையெனில், முடிவு Unknown.

உங்கள் application அந்த context-ஐ வைத்து என்ன செய்ய வேண்டும் என்பதைத் தீர்மானிக்கிறது. Policies route-க்கு route, actor class-க்கு actor class, basis-க்கு basis என எழுதப்படுகின்றன; allow, adapt, challenge, review மற்றும் rate-limit போன்ற outcomes-உடன். Default-ஆக எதுவும் enforce செய்யப்படாது: நீங்கள் ஒரு policy-ஐ உண்மையான traffic-க்கு எதிராக preview செய்து, அதை route by route, உங்கள் own code-இல் enforce செய்கிறீர்கள்.

Founding teams Node.js middleware, Next.js, edge integration, approved pages-இல் browser collector, generic HTTP API, அல்லது MCP server integration மூலம் evidence-ஐ சேகரிக்கலாம். integrations மற்றும் verifying signed agent requests குறித்த guide-ஐப் பாருங்கள், நடைமுறை படிகளுக்காக.

Proof of Actor, standard சொல்லும் அதே வரம்பை பின்பற்றுகிறது: verified signature request-ஐ எந்த key கையொப்பமிட்டது என்பதைக் கூறுகிறது, agent-க்கு authorization உண்டா என்பதை அல்ல. Authorization உங்களிடமே உள்ளது. evidence and limits பக்கம் ஒவ்வொரு result எதை ஆதரிக்க முடியும், எதை முடியாது என்பதைத் தெளிவாகக் கூறுகிறது.

தொடங்குங்கள்

Proof of Actor private beta-வில் உள்ளது. தேர்ந்தெடுக்கப்பட்ட founding developer teams, ஒப்புக்கொண்ட usage limits-இல், automatic billing இல்லாமல், 12 months வரை free access பெறலாம். early access-க்கு விண்ணப்பிக்கவும் மற்றும் signed agents எந்த routes-ஐ பயன்படுத்துவார்கள், அவர்களுடன் நீங்கள் என்ன செய்ய விரும்புகிறீர்கள் என்பதைக் கூறுங்கள்.

உருவாக்குநர்களுக்காக

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
evidence எவ்வளவு வலுவானது: Verified, Declared, Inferred அல்லது Unknown.
evidence
முடிவுக்குப் பின்னுள்ள signals, அதனால் உங்கள் team ஏன் என்பதைப் பார்க்க முடியும்.

observation mode-இல் தொடங்கவும்: முடிவுகளை உங்கள் logs-க்கு அடுத்ததாக பதிவு செய்யவும், நீங்கள் ஒரு policy-ஐத் தேர்வு செய்யும் வரை எதையும் மாற்றாதீர்கள். Node.js integration guide-ஐப் படிக்கவும்

அடிக்கடி கேட்கப்படும் கேள்விகள்

Web Bot Auth என்றால் என்ன?

Web Bot Auth என்பது IETF working group, webbotauth, மற்றும் அது தரநிலைப்படுத்தும் அணுகுமுறை ஆகியவற்றின் பெயர்: automated clients HTTP Message Signatures (RFC 9421) மூலம் HTTP requests-ஐ கையொப்பமிட்டு, தங்கள் public keys-ஐ வெளியிடுகின்றன, அதனால் websites எந்த operator ஒரு request அனுப்பியது என்பதை சரிபார்க்க முடியும்.

Web Bot Auth ஒரு முடிந்த standard ஆகிறதா?

இன்னும் இல்லை. 2026 நவம்பர் நிலவரப்படி, முக்கிய protocol document ஆன draft-ietf-webbotauth-httpsig-protocol, revision 01-இல் உள்ள working group Internet-Draft ஆக உள்ளது. RFC 9421, அது கட்டமைக்கும் signature format, வெளியிடப்பட்ட Proposed Standard ஆகும்.

செல்லுபடியாகும் Web Bot Auth signature agent-க்கு செயல்பட அனுமதி உள்ளது என்பதைக் குறிக்கிறதா?

இல்லை. அது எந்த key request-ஐ கையொப்பமிட்டது, மேலும் கையொப்பமிடப்பட்ட பகுதிகள் மாற்றப்படவில்லை என்பதைக் காட்டுகிறது. அந்த agent தரவைப் படிக்கலாமா, form-ஐ சமர்ப்பிக்கலாமா, அல்லது ஒரு குறிப்பிட்ட பயனருக்காக செயல்படலாமா என்பது உங்கள் application இன்னும் தீர்மானிக்கும் authorization முடிவு.

Product teams Web Bot Auth-ஐ தாங்களே implement செய்ய வேண்டுமா?

Sites signatures-ஐ verify செய்கின்றன; அவை automated clients-ஐயும் இயக்கவில்லை என்றால் வேறு எதையும் கையொப்பமிட தேவையில்லை. Verification-க்கு key directories-ஐ fetch செய்வது, அவற்றை பாதுகாப்பாக cache செய்வது, மற்றும் signatures-ஐச் சரிபார்ப்பது அடங்கும், இதை Proof of Actor போன்ற ஒரு tool உங்களுக்காக செய்யலாம்.

தங்கள் கோரிக்கைகளை கையொப்பமிடாத agents-ஐ நாம் என்ன செய்ய வேண்டும்?

கிடைக்கும் evidence அடிப்படையில் அவற்றை நடத்துங்கள்: declared, inferred அல்லது Unknown. சில காலம் signed மற்றும் unsigned traffic இரண்டின் கலவையை எதிர்பாருங்கள், மேலும் ஒரே site-wide rule-ஐ விட ஒவ்வொரு route-க்கும் fallback-ஐ அமைக்குங்கள்.

Proof of Actor Web Bot Auth-ஐ எப்படி பயன்படுத்துகிறது?

அது HTTP Message Signatures-ஐ வெளியிடப்பட்ட key-க்கு எதிராகச் சரிபார்க்கிறது, மற்றும் சரிபார்ப்பு வெற்றியடையும்போது, முடிவை verified basis-உடன் அறிவிக்கிறது. பிறகு உங்கள் policies verified agents-ஐ declared அல்லது Unknown traffic-இலிருந்து வேறுபட்டு நடத்த முடியும்.

உங்கள் app-ஐ யார் பயன்படுத்துகிறார்கள் என்பதை அறிந்துகொள்ளுங்கள்.

founding developers-இன் சிறிய குழுவுக்கான private beta.

முன்கூட்டிய அணுகலைப் பெறுகவிலை விவரங்களை காண்க

முதலில் பேச விரும்புகிறீர்களா? founders-உடன் பேசுங்கள்