यहाँ AI से कुछ सुझाव दिए गए हैं:
- कुकी/स्टोरेज प्रतिबंधों द्वारा अज्ञात सत्र टोकन अवरुद्ध। इनमें से कई चैट विजेट पहली बार लोड होने पर चुपचाप एक सत्र ID (कुकी या localStorage) बनाते हैं और इसे हर API कॉल से जोड़ते हैं। यदि किसी सहकर्मी का ब्राउज़र थर्ड-पार्टी कुकी या स्टोरेज को ब्लॉक करता है (Safari/Firefox ट्रैकिंग प्रोटेक्शन, प्राइवेट/इनकोग्निटो मोड, कॉर्पोरेट-प्रबंधित ब्राउज़र नीति, या uBlock/Privacy Badger/Brave Shields जैसी एक्सटेंशन), तो वह टोकन कभी नहीं बनता या भेजा जाता है — तब API कॉल एक प्रमाणीकरण-रहित अनुरोध की तरह दिखता है और "unauthorised" के रूप में अस्वीकार कर दिया जाता है।
- Origin/Referrer जाँच विफल हो रही है। यदि बैकएंड यह सत्यापित करता है कि अनुरोध paratext.org स्वयं से आ रहे हैं (वास्तविक प्रमाणीकरण के बजाय एक सामान्य हल्का अंतर्वेधन-रोधी उपाय), तो पृष्ठ के लोड होने के तरीके को बदलने वाली कोई भी चीज़ — एक कॉर्पोरेट वेब फ़िल्टर/प्रॉक्सी जो हेडर को पुनर्लेखन या हटा देता है, एक अनुवाद प्रॉक्सी, "रीडर मोड", या किसी अन्य ऐप के इन-ऐप ब्राउज़र के अंदर लिंक खोलना — पृष्ठ ठीक से रेंडर होने के बावजूद उस जाँच को तोड़ सकता है।
- कॉर्पोरेट प्रॉक्सी/SSL निरीक्षण हेडर हटा रहा है। SIL से जुड़े सहकर्मी अक्सर प्रबंधित नेटवर्क पर होते हैं जिनमें गहन पैकेट निरीक्षण या कंटेंट फ़िल्टरिंग होती है, जो आउटबाउंड API कॉल पर Authorization, Cookie, या कस्टम हेडर को हटा देती है, जबकि चैट UI स्वयं CDN से सामान्य रूप से लोड होता रहता है।
- साझा बैकएंड API कुंजी रेट/कोटा सीमा तक पहुँच रही है। यदि विजेट किसी साझा सर्वर-साइड कुंजी का उपयोग करके Claude की API जैसी किसी चीज़ के लिए प्रॉक्सी करता है, तो एक साथ डेमो ट्रैफिक का एक झटका (आप + 3 सहकर्मी एक मिनट के भीतर प्रॉम्प्ट्स भेज रहे हैं) एक रेट लिमिट को ट्रिप कर सकता है जिसे बैकएंड "too many requests" के बजाय "unauthorised" के रूप में रिपोर्ट करता है।
पुष्टि करने का सबसे तेज़ तरीका: एक सहकर्मी को ब्राउज़र DevTools → Network टैब खोलने, एक प्रॉम्प्ट दोबारा आज़माने, विफल अनुरोध पर क्लिक करने और वास्तविक HTTP स्थिति कोड (401 बनाम 403 बनाम 429) और रिस्पॉन्स बॉडी की जाँच करने को कहें — यह हमें निश्चित रूप से बताएगा कि इनमें से कौन सा है। यदि आप वह प्राप्त कर सकते हैं, तो मैं कारण को सटीक रूप से निर्धारित कर सकता हूँ।
Here are some suggestions from AI:
- Anonymous session token blocked by cookie/storage restrictions. Many of these chat widgets silently mint a session ID (cookie or localStorage) on first load and attach it to every API call. If a colleague's browser blocks third-party cookies or storage (Safari/Firefox tracking protection, private/incognito mode, corporate-managed browser policy, or an extension like uBlock/Privacy Badger/Brave Shields), that token never gets created or sent — the API call then looks like an unauthenticated request and gets rejected as "unauthorised."
- Origin/Referrer check failing. If the backend validates that requests come from paratext.org itself (a common lightweight anti-abuse measure instead of real auth), anything that changes how the page is loaded — a corporate web filter/proxy that rewrites or strips headers, a translation proxy, "Reader mode," or opening the link inside another app's in-app browser — can break that check even though the page renders fine.
- Corporate proxy/SSL inspection stripping headers. SIL-affiliated colleagues are often on managed networks with deep packet inspection or content filtering that strips Authorization, Cookie, or custom headers on outbound API calls, while the chat UI itself still loads normally from a CDN.
- Shared backend API key hitting a rate/quota limit. If the widget proxies to something like Claude's API using one shared server-side key, a burst of simultaneous demo traffic (you + 3 colleagues all firing prompts within a minute) could trip a rate limit that the backend reports as "unauthorised" rather than "too many requests."
Fastest way to confirm: have one colleague open browser DevTools → Network tab, retry a prompt, click the failed request, and check the actual HTTP status code (401 vs 403 vs 429) and response body — that will tell us definitively which of these it is. If you can grab that, I can pin down the cause precisely.
English से मशीन-अनुवादित
