以下是 AI 提供的一些建議：
- 匿名會話令牌被 Cookie/儲存限制阻擋。 許多這類聊天小工具在首次載入時會靜默地生成一個會話 ID（Cookie 或 localStorage），並將其附加到每個 API 呼叫中。如果同事的瀏覽器阻擋了第三方 Cookie 或儲存（Safari/Firefox 的追蹤保護、私人/無痕模式、企業管理的瀏覽器策略，或 uBlock/Privacy Badger/Brave Shields 等擴充功能），該令牌將無法建立或傳送——API 呼叫看起來就像未驗證的請求，並被拒絕為「unauthorised」。
- 來源/Referer 檢查失敗。 如果後端驗證請求是否來自 paratext.org 本身（一種常見的輕量級反濫用措施，而非真正的身份驗證），任何改變頁面載入方式的因素——企業網頁過濾器/代理伺服器重寫或移除標頭、翻譯代理、「閱讀模式」，或在其他應用程式的內建瀏覽器中開啟連結——都可能導致該檢查失敗，即使頁面正常顯示。
- 企業代理/SSL 檢查移除標頭。 SIL 相關同事通常處於具有深度封包檢查或內容過濾的管理網路中，這會移除出站 API 呼叫中的 Authorization、Cookie 或自訂標頭，而聊天 UI 本身仍可從 CDN 正常載入。
- 共用後端 API 金鑰觸發速率/配額限制。 如果小工具使用一個共用的伺服器端金鑰代理到類似 Claude API 的服務，同時發生的示範流量激增（您 + 3 位同事在一分鐘內發送提示）可能會觸發速率限制，後端將其報告為「unauthorised」而非「too many requests」。
最快的確認方法：請一位同事開啟瀏覽器 DevTools → Network 分頁，重新嘗試提示，點擊失敗的請求，並檢查實際的 HTTP 狀態碼（401 vs 403 vs 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
