दर सीमाएँ

Chastify लॉक सेशन, स्टोरेज, डिवाइस और नोटिफिकेशन सिस्टम की सुरक्षा के लिए एक्सटेंशन API ट्रैफिक को रेट-लिमिट करता है।

रेट लिमिट Chastify के माध्यम से रूट किए गए iframe ब्रिज ट्रैफिक और डेवलपर API कुंजी के साथ किए गए बैकएंड कॉल दोनों पर लागू होती हैं।

वर्तमान एक्सटेंशन बकेट

बकेट	सीमा	विशिष्ट एंडपॉइंट
पढ़ें	300/min	session.get, state.get, metadata.get, फ़ाइल पठन, नियमित-क्रिया स्थिति
लिखें	120/min	बैकएंड स्थिति लेखन, मेटाडेटा अपडेट, नियमित-क्रिया कॉन्फ़िगरेशन, सर्वर-सत्यापित रन निर्माण
अपलोड	10/min	रनटाइम और सेटअप फ़ाइल अपलोड
कार्रवाई	30/min	लॉक क्रियाएं, डिवाइस कमांड, कस्टम लॉग, कस्टम सूचनाएं, सर्वर-सत्यापित परिणाम निपटान
टोकन	30/min	आईफ्रेम सेशन लॉन्च/प्रमाणीकरण टोकन जनरेशन

सीमाओं का मूल्यांकन एक मिनट की अवधि में किया जाता है।

note

ये प्लेटफ़ॉर्म की डिफ़ॉल्ट सेटिंग्स हैं। Chastify एडमिन/साइट मालिक आधिकारिक या असामान्य रूप से अधिक उपयोग वाले एक्सटेंशन के लिए प्रति-एक्सटेंशन ओवरराइड कॉन्फ़िगर कर सकते हैं। ओवरराइड एक्सटेंशन ऐप कॉन्फ़िगरेशन में संग्रहीत होते हैं और तेज़ अनुरोध-पथ लुकअप के लिए Redis में थोड़े समय के लिए कैश किए जाते हैं।

info

अपलोड और एक्शन बकेट को रीड/स्टेट बकेट की तुलना में जानबूझकर अधिक सीमित रखा गया है। अपलोड स्टोरेज और बैंडविड्थ का उपयोग करते हैं। एक्शन लॉक स्थिति, डिवाइस, नोटिफिकेशन और उपयोगकर्ता को दिखाई देने वाले इतिहास को प्रभावित कर सकते हैं।

कुंजियों की गिनती कैसे की जाती है

रेट-लिमिट कुंजी में निम्नलिखित शामिल हैं:

• जब फर्स्ट-पार्टी यूआई किसी एंडपॉइंट को कॉल करता है तो Chastify उपयोगकर्ता आईडी प्रमाणित हो जाती है।
• जब आपका बैकएंड एक्सटेंशन सेशन एंडपॉइंट्स को कॉल करता है तो डेवलपर API कुंजी आईडी का उपयोग किया जाता है।
• अनाम या अप्रमाणित पथों के लिए आईपी पता
• उपलब्ध होने पर लक्ष्य sessionId या lockId

इसका मतलब यह है कि एक शोरगुल वाला एक्सटेंशन सेशन पूरे ग्लोबल एक्सटेंशन एपीआई बजट को खर्च नहीं करना चाहिए।

अनुशंसित ग्राहक व्यवहार

आपके iframe या बैकएंड को 429 Too Many Requests को एक सामान्य पुनः प्रयास योग्य स्थिति के रूप में मानना ​​चाहिए।

बार-बार होने वाली विफलताओं के लिए एक्सपोनेंशियल बैकऑफ़ का उपयोग करें:

async function callWithBackoff<T>(fn: () => Promise<T>, attempts = 4): Promise<T> {
  let delayMs = 500;

  for (let attempt = 1; attempt <= attempts; attempt += 1) {
    try {
      return await fn();
    } catch (error: any) {
      const status = error?.status ?? error?.response?.status;
      if (status !== 429 || attempt === attempts) throw error;

      await new Promise((resolve) => setTimeout(resolve, delayMs));
      delayMs *= 2;
    }
  }

  throw new Error("request_failed");
}

आईफ्रेम ब्रिज मार्गदर्शन

आईफ्रेम ब्रिज क्लाइंट के लिए:

• जब तक आपको नए लॉक डेटा की आवश्यकता न हो, पेज के जीवनकाल के लिए session.get के परिणामों को कैश करें।
• अस्थायी यूआई परिवर्तनों को स्थानीय रूप से संग्रहीत करें और विश्वसनीय परिवर्तनों को अपने बैकएंड पर भेजें।
• तेज़ गति से होने वाली पोलिंग लूप से बचें। उपयोगकर्ता द्वारा ट्रिगर किए गए रीड या धीमे रिफ्रेश अंतराल को प्राथमिकता दें।

डिबाउंस्ड बैकएंड सेव का उदाहरण:

let saveTimer: number | undefined;

function scheduleStateSave(data: Record<string, unknown>) {
  window.clearTimeout(saveTimer);
  saveTimer = window.setTimeout(() => {
    fetch("/your-extension-backend/state", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(data),
    }).catch(console.error);
  }, 500);
}

बैकएंड एक्सटेंशन मार्गदर्शन

डेवलपर एपीआई कुंजी के साथ बैकएंड कॉल के लिए:

• विशेषाधिकार प्राप्त कार्यों को सर्वर द्वारा सत्यापित और उपयोगकर्ता द्वारा ट्रिगर किया जाना चाहिए।
• PUT/PATCH /api/extensions/sessions/:sessionId/state का उपयोग केवल अपने बैकएंड से डेवलपर API क्रेडेंशियल के साथ करें।
• यदि पहले प्रयास में सफलता मिली हो तो लॉक संबंधी क्रियाओं को अंधाधुंध दोबारा करने का प्रयास न करें।
• गेम/चैलेंज सेटलमेंट को रन आईडी के साथ आइडम्पोटेंट बनाएं।
• फ़ाइलें तभी अपलोड करें जब उपयोगकर्ता स्पष्ट रूप से कोई फ़ाइल सबमिट करे।
• यदि आपको उच्च आवृत्ति वाले टेलीमेट्री डेटा की आवश्यकता है, तो अपने स्वयं के बाहरी रिकॉर्ड संग्रहित करें।

warning

अपुष्ट ब्राउज़र कॉल की भरपाई के लिए एक्शन लिमिट कभी न बढ़ाएं। ब्राउज़र आईफ़्रेम कोड विश्वसनीय नहीं है। Chastify को कॉल करने से पहले संवेदनशील परिवर्तनों को आपके बैकएंड द्वारा मान्य किया जाना चाहिए।

मुझे किस बाल्टी की उम्मीद करनी चाहिए?

सामान्य उदाहरण:

• GET /api/extensions/sessions/:sessionId रीड बकेट का उपयोग करता है।
• GET /api/extensions/sessions/:sessionId/state रीड बकेट का उपयोग करता है।
• PUT/PATCH /api/extensions/sessions/:sessionId/state राइट बकेट का उपयोग करता है।
• POST /api/extensions/sessions/:sessionId/files अपलोड बकेट का उपयोग करता है।
• POST /api/extensions/sessions/:sessionId/action एक्शन बकेट का उपयोग करता है।
• POST /api/extensions/sessions/:sessionId/device-command एक्शन बकेट का उपयोग करता है।
• POST /api/extensions/sessions/:sessionId/logs/custom एक्शन बकेट का उपयोग करता है।
• POST /api/extensions/sessions/:sessionId/notifications/custom एक्शन बकेट का उपयोग करता है।
• GET /api/extensions/sessions/:sessionId/auth टोकन बकेट का उपयोग करता है।

भविष्य के दानेदार बाल्टियाँ

वर्तमान में ये श्रेणियाँ व्यापक हैं। उदाहरण के लिए, डेवलपर API के विस्तार के साथ Chastify इन्हें और भी विभाजित कर सकता है:

• state.write
• metadata.write
• lock.action
• notifications.custom
• device.command
• files.upload

आधिकारिक या अनुमोदित उच्च-मात्रा वाले एक्सटेंशन की वैध आवश्यकता होने पर Chastify प्रशासक/साइट स्वामी प्रति-एक्सटेंशन सीमा बढ़ा सकते हैं। क्लाइंट को इस प्रकार डिज़ाइन करें कि 429 हैंडलिंग सामान्य हो और सटीक बकेट नामों या निश्चित प्लेटफ़ॉर्म डिफ़ॉल्ट पर निर्भर न हो।