സ്ഥിരീകരിച്ച ഓട്ടോമേഷൻ

സ്ഥിരീകരിച്ച ഓട്ടോമേറ്റഡ് അഭ്യർത്ഥനകളെ തിരിച്ചറിയുക

ഒരു ഓട്ടോമേറ്റഡ് ക്ലയന്റ് അതിന്റെ അഭ്യർത്ഥനകളിൽ സിഗ്നേച്ചർ ചേർക്കുമ്പോൾ, നിങ്ങളുടെ application ആ സിഗ്നേച്ചർ പരിശോധിച്ച് വിളിക്കുന്നവനെ അതനുസരിച്ച് കൈകാര്യം ചെയ്യാം. Proof of Actor ആ പരിശോധനയെ വ്യക്തവും റൂട്ടുചെയ്യാവുന്നതുമായ ഫലമാക്കി മാറ്റുന്നു.

Early Access നേടുക ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് പര്യവേക്ഷണം ചെയ്യുക

രചിച്ചത് Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

ചുരുക്ക ഉത്തരം

സ്ഥിരീകരിച്ച ഓട്ടോമേറ്റഡ് അഭ്യർത്ഥനകൾക്ക് RFC 9421 HTTP Message Signature പോലുള്ള ഒരു ക്രിപ്‌റ്റോഗ്രാഫിക് സിഗ്നേച്ചർ ഉണ്ടായിരിക്കും, അത് അഭ്യർത്ഥനയെ പ്രസിദ്ധീകരിച്ച ഒരു കീയുമായി ബന്ധിപ്പിക്കുന്നു. Proof of Actor സിഗ്നേച്ചർ പരിശോധിച്ച് സ്ഥിരീകരിച്ച അടിസ്ഥാനത്തോടെ ഫലം റിപ്പോർട്ട് ചെയ്യുന്നു, അതേസമയം authorization നിങ്ങളുടെ തീരുമാനമായിരിക്കും.

എല്ലാ ഓട്ടോമേറ്റഡ് trafficഉം ഒരുപോലെയല്ല

ഓട്ടോമേറ്റഡ് ക്ലയന്റുകൾ ഓരോ മിനിറ്റിലും നിങ്ങളുടെ applicationയിലെത്തുന്നു: search crawlers, monitoring tools, പേജുകൾ ഒരു userക്കായി കൊണ്ടുവരുന്ന partner integrations, AI assistants, tasks പൂർത്തിയാക്കുന്ന autonomous agents. വർഷങ്ങളോളം, മിക്ക applicationsക്കും അവയെ വേർതിരിക്കാൻ ഉണ്ടായിരുന്നത് user-agent header മാത്രമായിരുന്നു, ഏതൊരു ക്ലയന്റിനും എന്തും ആയി സജ്ജമാക്കാൻ കഴിയുന്ന ഒരു string.

അത് application ടീമുകളെ ഒരു പ്രയാസത്തിലാക്കുന്നു. എല്ലാ automationനെയും സംശയത്തോടെ കാണുക, അതോടെ നിങ്ങളുടെ customers ആശ്രയിക്കുന്ന legitimate agentsയുടെ experience താഴ്ന്നുപോകും. headerനെ വിശ്വസിക്കുക, അപ്പോൾ ഏവർക്കും അറിയപ്പെടുന്ന ഒരു crawler ആണെന്ന് അവകാശപ്പെടാം.

സ്ഥിരീകരിച്ച ഓട്ടോമേറ്റഡ് അഭ്യർത്ഥനകൾ ഈ സമവാക്യം മാറ്റുന്നു. ഒരു ഓട്ടോമേറ്റഡ് ക്ലയന്റ് അത് പ്രസിദ്ധീകരിച്ചിട്ടുള്ള key ഉപയോഗിച്ച് അതിന്റെ അഭ്യർത്ഥനകളിൽ ഒപ്പിടുമ്പോൾ, നിങ്ങളുടെ application ആ സിഗ്നേച്ചർ പരിശോധിച്ച്, ക്രിപ്‌റ്റോഗ്രാഫിക് ആയി, ഏത് ക്ലയന്റാണ് അഭ്യർത്ഥന ഒപ്പിട്ടത് എന്ന് അറിയാൻ കഴിയും. Proof of Actor ആ പരിശോധനയെ നിങ്ങളുടെ code route ചെയ്യാൻ കഴിയുന്ന ഒറ്റ, സ്ഥിരതയുള്ള actor result-ന്റെ ഭാഗമാക്കുന്നു. ആ പരിശോധന എന്താണ് സ്ഥാപിക്കുന്നത്, എന്തല്ല സ്ഥാപിക്കുന്നത് എന്നതിനെ കൂടുതൽ അടുത്ത് കാണാൻ signed AI agent requests എന്താണ് തെളിയിക്കുന്നത് വായിക്കുക.

request signing എങ്ങനെ പ്രവർത്തിക്കുന്നു

ഓട്ടോമേറ്റഡ് trafficയ്ക്കുള്ള ഉയർന്നുവരുന്ന സമീപനം HTTP message signatures ഉപയോഗിക്കുന്നു, അവ RFC 9421-ൽ standardized ആണ്, ഇത് ഒരു HTTP message-ിലെ components-ലൂടെ signatures എങ്ങനെ സൃഷ്ടിക്കാം, encode ചെയ്യാം, verify ചെയ്യാം എന്നിവ നിർവചിക്കുന്നു. ക്ലയന്റ് ഓരോ അഭ്യർത്ഥനയുടെയും തിരഞ്ഞെടുത്ത ഭാഗങ്ങളിൽ private key ഉപയോഗിച്ച് ഒപ്പിടുകയും headers-ൽ signatureയും അതിന്റെ parameters-ഉം ഉൾപ്പെടുത്തുകയും ചെയ്യുന്നു. അത് നിയന്ത്രിക്കുന്ന ഒരു തിരിച്ചറിയലുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന സ്ഥലത്ത്, സാധാരണയായി അതിന്റെ domain-ൽ, അനുബന്ധ public key പ്രസിദ്ധീകരിക്കുന്നു.

അഭ്യർത്ഥന എത്തുമ്പോൾ, receiver പ്രസിദ്ധീകരിച്ച key എടുക്കുകയോ തിരയുകയോ ചെയ്ത്, signed content പുനർനിർമ്മിച്ച്, signature പരിശോധിക്കുന്നു. അത് സാധൂകരിച്ചാൽ, ആ അഭ്യർത്ഥന ആ key കൈവശം വച്ചിരുന്ന holder ആണ് ഒപ്പിട്ടത്. ഓട്ടോമേറ്റഡ് traffic signing സംബന്ധിച്ച ജോലി IETFയിലെ Web Bot Auth working group-ൽ തുടരുന്നു, അതിന്റെ charter crawlers, end usersക്കായി പ്രവർത്തിക്കുന്ന AI agents പോലുള്ള ഓട്ടോമേറ്റഡ് clientsനെ cryptographically authenticating ചെയ്യുന്നതാണ് ഉൾക്കൊള്ളുന്നത്; Web Bot Auth glossary entry അത് സംഗ്രഹിക്കുന്നു. signed AI agent requests എന്താണ് തെളിയിക്കുന്നത് എന്ന blog post ഒരു സ്ഥിരീകരിച്ച അഭ്യർത്ഥനയെ അറ്റം മുതൽ അറ്റം വരെ വിശദീകരിക്കുന്നു, കൂടാതെ APIs use case ആദ്യം verification എവിടെയാണ് ഏറ്റവും പ്രയോജനപ്രദമെന്ന് കാണിക്കുന്നു.

signed agent requests പരിശോധിക്കൽ എന്ന guide timestamps, replay windows, key caching എന്നിവ ഉൾപ്പെടെ mechanics വിശദമായി ഉൾക്കൊള്ളുന്നു.

ഒരു സ്ഥിരീകരിച്ച സിഗ്നേച്ചർ എന്താണ് തെളിയിക്കുന്നത്, എന്തല്ല തെളിയിക്കുന്നത്

സ്ഥിരീകരിച്ച ഓട്ടോമേറ്റഡ് അഭ്യർത്ഥനകളെ നന്നായി കൈകാര്യം ചെയ്യുന്നതിലെ ഏറ്റവും പ്രധാനപ്പെട്ട ഭാഗം ഈ വ്യത്യാസമാണ്.

സാധുവായ ഒരു സിഗ്നേച്ചർ, അഭ്യർത്ഥന പ്രസിദ്ധീകരിച്ച തിരിച്ചറിയലുമായി ബന്ധമുള്ള ഒരു key ഉപയോഗിച്ച് ഒപ്പിട്ടതാണ് എന്ന് തെളിയിക്കുന്നു. key operatorന്റെ domain-നേതുടങ്ങിയതാണെങ്കിൽ, ആ അഭ്യർത്ഥന ആ operatorന്റെ key കൈവശമുള്ള ഒരു ക്ലയന്റിൽ നിന്നാണ് വന്നത്.

സാധുവായ ഒരു സിഗ്നേച്ചർ ഇവ തെളിയിക്കുന്നില്ല:

agentനെ ആരാണ് നിർദ്ദേശിച്ചത്, അല്ലെങ്കിൽ ഈ actionക്ക് ഒരു person ചോദിച്ചിട്ടുണ്ടോ എന്ന്;
ഒരു person agentയ്ക്ക് authority കൈമാറിയതായി;
operatorന്റെ പിന്നിലുള്ള യഥാർത്ഥ നിയമപരമായ identity;
അഭ്യർത്ഥിച്ച action നിങ്ങളുടെ applicationയിൽ സുരക്ഷിതമാണോ അല്ലെങ്കിൽ അനുവദനീയമാണോ എന്ന്.

അവ വേറിട്ട ചോദ്യങ്ങളാണ്. നിങ്ങളുടെ application സ്വന്തം credentials, authorization model, policy എന്നിവ ഉപയോഗിച്ച് അവയ്ക്ക് മറുപടി നൽകുന്നു. Proof of Actor അവയെ ഉദ്ദേശ്യപൂർവ്വം വേർതിരിച്ച് വയ്ക്കുന്നു, കൂടാതെ Detection & Limitations എന്ന പേജ് ഓരോ തരത്തിലുള്ള തെളിവും എന്താണ് സ്ഥാപിക്കാനാകുന്നത് എന്ന് കൃത്യമായി വ്യക്തമാക്കുന്നു.

Proof of Actor സ്ഥിരീകരിച്ച ഓട്ടോമേറ്റഡ് അഭ്യർത്ഥനകളെ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു

Detect

നിങ്ങളുടെ integration, signature headers ഉൾപ്പെടെയുള്ള അഭ്യർത്ഥന context Proof of Actor-ലേക്ക് നൽകുന്നു. Signatures പ്രസിദ്ധീകരിച്ച keys-ക്കെതിരെ പരിശോധിക്കുന്നു. സാധൂകരിക്കുന്ന അഭ്യർത്ഥനകൾക്ക് verified അടിസ്ഥാനത്തോടെ രേഖപ്പെടുത്തുന്നു. സ്വയം പേരിടുന്ന ക്ലയന്റുകൾ declared ആയി രേഖപ്പെടുത്തുന്നു. Behavioral patterns inferred ആയി രേഖപ്പെടുത്തുന്നു. മുന്നോട്ട് പോകാൻ മതിയായ വിവരമില്ലെങ്കിൽ, ഫലം Unknown ആയിരിക്കും. ഒരു cryptographic check വിജയിച്ചില്ലെങ്കിൽ ഒന്നും verified ആയി ഉയർത്തുന്നില്ല.

Understand

ഏത് verified operators ആണ് നിങ്ങളുടെ application വിളിക്കുന്നത്, അവർ ഏത് routes ആണ് ഉപയോഗിക്കുന്നത്, എത്രതവണ, അത് declared, unknown automation-ുമായി എങ്ങനെ താരതമ്യപ്പെടുന്നു എന്നിവ കാണുക. ഓരോ ഫലത്തിലുമുള്ള evidence summary, ഏത് key ഉം identifier ഉം ഉൾപ്പെട്ടിരുന്നു എന്ന് പറയുന്നു, അതിനാൽ നിങ്ങളുടെ ടീമിന് ഏതൊരു അഭ്യർത്ഥനയും വേഗത്തിൽ അന്വേഷിക്കാനാകും.

Route

നിങ്ങളുടെ policies-ൽ ഈ basis ഉപയോഗിക്കുക. സാധാരണ patterns ഇവയാണ്:

verified agents-ക്ക് read-only routes-ൽ, ഉദാഹരണത്തിന് ഒരു API അല്ലെങ്കിൽ ഒരു pageന്റെ Markdown പതിപ്പിൽ, ഘടിതമായ response നൽകുക.
നിങ്ങൾ തിരിച്ചറിയുന്ന verified operators-യ്ക്ക് rate limits ഉയർത്തുക, അതേസമയം declared clients-ക്ക് standard limits നിലനിർത്തുക.
signature എന്ത് പറഞ്ഞാലും ഓരോ write route-ലും നിങ്ങളുടെ നിലവിലുള്ള authorization നിലനിർത്തുക.
ഓരോ route-ലും unsigned, Unknown വിളിക്കുന്നവർക്കായി വ്യക്തമായ fallback നിർവചിക്കുക.

തീരുമാനം നിങ്ങളുടെ policies എടുക്കുന്നു; തെളിവ് നൽകുന്നത് Proof of Actor ആണ്.

user-agent header മാത്രം മതിയാകാത്തത് എന്തുകൊണ്ട്

User-agent strings declarations ആണ്. ഏതൊരു ക്ലയന്റും ഏതൊരു valueയും അയയ്ക്കാം, കൂടാതെ user-agent spoofing-ക്ക് പ്രത്യേക skill ആവശ്യമില്ല. അതുകൊണ്ടാണ് crawler operators അവരുടെ സ്വന്തം checks പ്രസിദ്ധീകരിക്കുന്നത്: Google verifying Googlebot-നായി reverse, forward DNS lookups, പ്രസിദ്ധീകരിച്ച IP ranges എന്നിവ രേഖപ്പെടുത്തുന്നു, Bing verifying Bingbot-നായി ഒരു DNS check രേഖപ്പെടുത്തുന്നു, OpenAI തങ്ങളുടെ crawlers and user agents ഓരോന്നിനും IP range files പ്രസിദ്ധീകരിക്കുന്നു. Proof of Actor ഒരു user-agent claim declared evidence ആയി കണക്കാക്കുന്നു, ഒരിക്കലും verification ആയി അല്ല. അതായത്, സാധുവായ signature ഇല്ലാതെ അറിയപ്പെടുന്ന ഒരു crawler ആണെന്ന് അവകാശപ്പെടുന്ന ഒരു ക്ലയന്റിനെ declared അല്ലെങ്കിൽ inferred basis-ോടെ റിപ്പോർട്ട് ചെയ്യും, അതേസമയം നിങ്ങളുടെ policy, സ്വന്തം identity തെളിയിച്ച ഒരു clientനിൽ നിന്ന് അതിനെ വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യാം.

സ്ഥിരീകരിച്ച ഓട്ടോമേറ്റഡ് അഭ്യർത്ഥനകളെ മൂല്യമുള്ളതാക്കുന്നത് ഇതാണ്: അവരുടെ header പകർത്തുന്ന എല്ലാവരിലേക്കും trust വ്യാപിപ്പിക്കാതെ, അത് അർഹിക്കുന്ന clients-ിലേക്ക് trust നീട്ടുന്നതിനുള്ള വിശ്വസനീയമായ മാർഗം അവർ നിങ്ങൾക്ക് നൽകുന്നു.

identity evidence, credentials, authorization

ഓട്ടോമേറ്റഡ് clients-ന് സേവനം നൽകുന്ന ഏതൊരു applicationലും മൂന്ന് പാളികൾ ഒരുമിച്ച് പ്രവർത്തിക്കുന്നു:

Identity evidence: ഈ അഭ്യർത്ഥന ഒപ്പിട്ടത് ഏത് client ആണ്? ഒരു verified signature അതിന് മറുപടി നൽകുന്നു.
Credentials: ഏത് account ആണ് ഉത്തരവാദി? നിങ്ങളുടെ API key, token അല്ലെങ്കിൽ session അതിന് മറുപടി നൽകുന്നു.
Authorization: ഈ വിളിക്കുന്നവന് ഇത് ചെയ്യാനാകുമോ? നിങ്ങളുടെ permission model അതിന് മറുപടി നൽകുന്നു.

Proof of Actor ആദ്യ പാളിയെ ശക്തമാക്കുകയും അതിനെ ദൃശ്യമായതാക്കുകയും ചെയ്യുന്നു. അത് identity അല്ലെങ്കിൽ delegation credentials പുറപ്പെടുവിക്കുന്നില്ല, കൂടാതെ നിങ്ങളുടെ authorization-നെ മാറ്റിസ്ഥാപിക്കുന്നതുമല്ല. പാളികളെ വേർതിരിച്ച് നിലനിർത്തുന്നതാണ് കുറഞ്ഞ അപകടസാധ്യതയുള്ള routes-ൽ verified agents-നോട് ഉദാരമായി പെരുമാറാനും, ഉയർന്ന പ്രഭാവമുള്ളവയിൽ ജാഗ്രത പാലിക്കാനും നിങ്ങളെ സഹായിക്കുന്നത്.

ഇത് എവിടെയാണ് ചേരുന്നത്

Proof of Actor നിങ്ങളുടെ gateway, authentication, rate limiting എന്നിവയ്‌ക്കൊപ്പം നിലകൊള്ളുന്നു. Integrations server-side middleware ആയി, edge-ൽ, നിങ്ങളുടെ MCP server-ൽ അല്ലെങ്കിൽ generic HTTP integration വഴി പ്രവർത്തിക്കുന്നു, ഓരോ founding team-നോടും നേരിട്ട് നൽകപ്പെടുന്നു. നിങ്ങളുടെ traffic കൂടുതലും APIs, tools എന്നിവയാണെങ്കിൽ, APIs , MCP Servers use cases പ്രധാനപ്പെട്ട patterns കാണിക്കുന്നു.

observation mode-ൽ ആരംഭിക്കുക

ഓരോ integrationഉം observation mode-ൽ ആരംഭിക്കുന്നു. നിങ്ങളുടെ application എങ്ങനെ പ്രതികരിക്കുന്നു എന്ന് മാറ്റാതെ ഫലങ്ങൾ രേഖപ്പെടുത്തുന്നു, അതിനാൽ നിങ്ങളുടെ ഓട്ടോമേറ്റഡ് traffic-ിൽ എത്ര ഭാഗം verified ആണെന്ന്, ഏത് operators ആണ് ഒപ്പിടുന്നത്, unknown rate എവിടെയാണ് ഏറ്റവും കൂടുതലെന്ന് നിങ്ങൾക്ക് കാണാം. തെളിവ് അവയെ പിന്തുണയ്ക്കുമ്പോൾ മാത്രമേ route by route policies പിന്നീട് വരൂ. How It Works മുഴുവൻ flow വിശദീകരിക്കുന്നു.

verification വിശ്വസനീയമാക്കുന്ന പ്രായോഗിക വിശദാംശങ്ങൾ

Signature checking ചുറ്റുമുള്ള വിശദാംശങ്ങൾ എത്ര നന്നാണോ അത്ര മാത്രമേ നല്ലതാകൂ. കുറച്ച് practices verified automated requests production-ൽ വിശ്വാസയോഗ്യമാക്കുന്നു.

تازഗി പരിശോധിക്കുക

RFC 9421 created , expires signature parameters നിർവചിക്കുന്നു, കൂടാതെ signed requests സാധാരണ അവ വഹിക്കുന്നു. ചുരുങ്ങിയ window-നു പുറത്തുള്ള signatures നിരസിക്കുക, അങ്ങനെ പിടിച്ചെടുത്ത ഒരു അഭ്യർത്ഥന പിന്നീട് replay ചെയ്യാൻ കഴിയില്ല.

keys ബുദ്ധിപൂർവ്വം cache ചെയ്യുക

ഓരോ അഭ്യർത്ഥനയിലും operatorന്റെ പ്രസിദ്ധീകരിച്ച keys എടുക്കുന്നത് latency കൂട്ടും. അവ യുക്തിസഹമായ ഒരു കാലയളവിലേക്ക് cache ചെയ്യുക, കൂടാതെ unknown key identifier ഉപയോഗിച്ച് ഒരു signature പരാജയപ്പെടുമ്പോൾ refresh ചെയ്യുക, key rotation false failures സൃഷ്ടിക്കാതിരിക്കാനായി.

അഭ്യർത്ഥനയുടെ ശരിയായ ഭാഗങ്ങളിൽ ഒപ്പിടുക

Timestamp മാത്രം ഉൾക്കൊള്ളുന്ന ഒരു signature വളരെ കുറച്ച് മാത്രമേ തെളിയിക്കൂ. signed components-ൽ method, path, host എന്നിവ ഉൾപ്പെട്ടിട്ടുണ്ടെന്ന് പരിശോധിക്കുക, അങ്ങനെ നിങ്ങളുടെ application യഥാർത്ഥത്തിൽ സ്വീകരിച്ച അഭ്യർത്ഥനയോട് signature ബന്ധപ്പെടും.

തെളിവ് രേഖപ്പെടുത്തുക

ഓരോ verified അഭ്യർത്ഥനയോടൊപ്പം key identifier, പ്രസിദ്ധീകരിച്ച identifier, result എന്നിവ സൂക്ഷിക്കുക. അസാധാരണമായ എന്തെങ്കിലും സംഭവിച്ചാൽ, ഏത് client എന്താണ്, എപ്പോൾ ഒപ്പിട്ടത് എന്ന് നിങ്ങളുടെ ടീമിന് കൃത്യമായി കാണാൻ കഴിയും.

Proof of Actor ഈ checks Detect step-ന്റെ ഭാഗമായി കൈകാര്യം ചെയ്യുകയും, നിങ്ങളുടെ policies വായിക്കാവുന്ന basis ആയി outcome റിപ്പോർട്ട് ചെയ്യുകയും ചെയ്യുന്നു, അതിനാൽ നിങ്ങളുടെ application code ലളിതമായി തുടരുന്നു.

founding developer program-ൽ ചേരുക

Proof of Actor private beta-യിലാണ്. തെരഞ്ഞെടുക്കപ്പെട്ട founding development ടീമുകൾക്ക്, സമ്മതിച്ച usage limits-ന്റെ ഉള്ളിൽ, ഞങ്ങളുടെ engineers-ന്റെ നേരിട്ടുള്ള integration support-ോടെ up to 12 months of free access ലഭിക്കും.

സ്ഥിരീകരിച്ചവയെ വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യണമെന്നുണ്ടെങ്കിൽ, apply for early access. നിങ്ങളുടെ application-നെക്കുറിച്ചും നിങ്ങൾ കാണുന്ന automated callers-നെക്കുറിച്ചും ഞങ്ങളോട് പറയുക, പിന്നെ Proof of Actor എങ്ങനെ ചേരുന്നു എന്ന് ഞങ്ങൾ കാണിച്ചുതരാം.

ഉറവിടങ്ങൾ

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.
Overview of OpenAI crawlers, OpenAI.

ഡെവലപ്പർമാർക്കായി

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: result-ിന്റെ പിന്നിലെ signals, അതുവഴി നിങ്ങളുടെ team-ന് കാരണം കാണാൻ കഴിയും.

observation mode-ൽ ആരംഭിക്കുക: നിങ്ങളുടെ logs-ിന് ഒപ്പം results രേഖപ്പെടുത്തുക, നിങ്ങൾ ഒരു policy തിരഞ്ഞെടുക്കും വരെ ഒന്നും മാറ്റരുത്. Node.js integration guide വായിക്കുക

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

സ്ഥിരീകരിച്ച ഓട്ടോമേറ്റഡ് അഭ്യർത്ഥന എന്താണ്?

അറിയപ്പെടുന്ന ഒരു തിരിച്ചറിയലിനായി, ഉദാഹരണത്തിന് operatorന്റെ domain, പ്രസിദ്ധീകരിച്ചിരിക്കുന്ന ഒരു കീയുമായി അതിന്റെ ക്രിപ്‌റ്റോഗ്രാഫിക് സിഗ്നേച്ചർ സാധൂകരിക്കുന്ന ഒരു ഓട്ടോമേറ്റഡ് ക്ലയന്റിൽ നിന്നുള്ള അഭ്യർത്ഥനയാണ് അത്. ഏത് ക്ലയന്റാണ് അഭ്യർത്ഥന ഒപ്പിട്ടത് എന്ന് ഇത് കാണിക്കുന്നു.

സ്ഥിരീകരിച്ച സിഗ്നേച്ചർ agentക്ക് authorization ഉണ്ടെന്ന് അർത്ഥമാക്കുമോ?

ഇല്ല. ഒരു സിഗ്നേച്ചർ ഒരു അഭ്യർത്ഥനയെ ഒരു കീയുമായി, അതിന്റെ പ്രസിദ്ധീകരിച്ച തിരിച്ചറിയലുമായി ബന്ധിപ്പിക്കുന്നു. ആ ക്ലയന്റിന് ഒരു action നടത്താൻ കഴിയുമോ എന്നത് നിങ്ങളുടെ application എടുക്കുന്ന വേറിട്ട authorization തീരുമാനമാണ്.

തങ്ങളുടെ അഭ്യർത്ഥനകളിൽ സിഗ്നേച്ചർ ചേർക്കാത്ത ഓട്ടോമേറ്റഡ് ക്ലയന്റുകളെക്കുറിച്ച് എന്ത് ചെയ്യും?

Proof of Actor അവരെ ഇപ്പോഴും വർഗ്ഗീകരിക്കുന്നു, ലഭ്യമെങ്കിൽ declared, inferred തെളിവുകൾ ഉപയോഗിച്ച്, തെളിവ് മതിയായില്ലെങ്കിൽ Unknown എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. ഓരോ ഫലവും അതിന്റെ അടിസ്ഥാനവും വ്യക്തമാക്കുന്നു.

ഒരു user-agent stringക്ക് ഒരു ക്ലയന്റിനെ സ്ഥിരീകരിക്കാനാകുമോ?

ഇല്ല. User-agent strings അനുകരിക്കാൻ വളരെ എളുപ്പമാണ്, അതിനാൽ അവ ഒരു declaration ആയി കണക്കാക്കപ്പെടുന്നു, verification ആയി അല്ല. ക്രിപ്‌റ്റോഗ്രാഫിക് സിഗ്നേച്ചറുകളാണ് ഒരു അഭ്യർത്ഥനയെ പരിശോധിക്കാവുന്നതാക്കുന്നത്.

ഞാൻ എങ്ങനെ തുടങ്ങാം?

early access അപേക്ഷിക്കുക. Founding ടീമുകൾ observation mode-ൽ ആരംഭിക്കുകയും, സമ്മതിച്ച usage limits-ന്റെ ഉള്ളിൽ തെരഞ്ഞെടുക്കപ്പെട്ട ടീമുകൾക്ക് up to 12 months free ലഭിക്കുകയും ചെയ്യാം.

നിങ്ങളുടെ app ഉപയോഗിക്കുന്നത് ആരാണെന്ന് അറിയുക.

ചെറിയൊരു founding developers ഗ്രൂപ്പിനായുള്ള private beta.

Early Access നേടുക വിലകൾ കാണുക

ആദ്യം സംസാരിക്കണമോ? സ്ഥാപകരുമായി സംസാരിക്കുക