以下是 AI 提出的一些建议：
- 匿名会话令牌被 Cookie/存储限制阻止。 许多此类聊天小部件在首次加载时会静默生成一个会话 ID（Cookie 或 localStorage），并将其附加到每个 API 调用中。如果同事的浏览器阻止第三方 Cookie 或存储（Safari/Firefox 的跟踪保护、隐私/隐身模式、企业管理的浏览器策略，或 uBlock/Privacy Badger/Brave Shields 等扩展程序），该令牌将永远不会创建或发送——API 调用随后看起来像是未认证请求，并被拒绝为“unauthorised”。
- 来源/引用检查失败。 如果后端验证请求是否来自 paratext.org 本身（一种常见的轻量级反滥用措施，而非真正的身份验证），任何改变页面加载方式的因素——重写或剥离标头的企业 Web 过滤器/代理、翻译代理、“阅读模式”，或在另一个应用的内嵌浏览器中打开链接——都可能导致该检查失败，即使页面渲染正常。
- 企业代理/SSL 检查剥离标头。 SIL 关联的同事通常位于具有深度包检测或内容过滤的管理网络上，这些网络会剥离出站 API 调用中的 Authorization、 Cookie 或自定义标头，而聊天 UI 本身仍可从 CDN 正常加载。
- 共享后端 API 密钥触及速率/配额限制。 如果小部件使用一个共享的服务器端密钥代理到类似 Claude API 的服务，突发的大量同时演示流量（你 + 3 位同事在一分钟内发送提示）可能会触发速率限制，后端将其报告为“unauthorised”而非“too many requests”。
最快的确认方法：让一位同事打开浏览器 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
