Вот несколько предположений от ИИ:
Анонимный токен сессии заблокирован из-за ограничений на файлы cookie/хранилище. Многие такие виджеты чата при первой загрузке незаметно создают идентификатор сессии (в файле cookie или localStorage) и добавляют его к каждому API-запросу. Если браузер коллеги блокирует сторонние файлы cookie или хранилище (защита от отслеживания в Safari/Firefox, приватный/инкогнито-режим, корпоративная политика управления браузером или расширение вроде uBlock/Privacy Badger/Brave Shields), этот токен так и не будет создан или отправлен — тогда API-запрос будет выглядеть как неавторизованный и будет отклонён с ошибкой «unauthorised».Сбой проверки Origin/Referrer. Если бэкенд проверяет, что запросы исходят именно с paratext.org (распространённая лёгкая мера защиты от злоупотреблений вместо полноценной аутентификации), то всё, что меняет способ загрузки страницы — корпоративный веб-фильтр/прокси, переписывающий или удаляющий заголовки, прокси для перевода, «режим чтения» или открытие ссылки во встроенном браузере другого приложения, — может нарушить эту проверку, даже если сама страница отображается нормально.Корпоративный прокси/проверка SSL удаляет заголовки. Коллеги, связанные с SIL, часто находятся в управляемых сетях с глубокой инспекцией пакетов или контент-фильтрацией, которые удаляют заголовки Authorization, Cookie или пользовательские заголовки в исходящих API-запросах, в то время как сам интерфейс чата по-прежнему загружается нормально с CDN.Общий ключ API бэкенда достиг лимита частоты/квоты. Если виджет проксирует запросы к API, например Claude, используя один общий серверный ключ, всплеск одновременного трафика (вы + 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 Показать оригинал
