Voici quelques suggestions de l'IA :
- Jeton de session anonyme bloqué par des restrictions de cookies ou de stockage. Beaucoup de ces widgets de chat génitent silencieusement un identifiant de session (cookie ou localStorage) au premier chargement et l'attachent à chaque appel API. Si le navigateur d'un collègue bloque les cookies tiers ou le stockage (protection contre le suivi de Safari/Firefox, mode privé/ navigation incognito, politique de navigateur gérée par l'entreprise, ou une extension comme uBlock/Privacy Badger/Brave Shields), ce jeton n'est jamais créé ni envoyé — l'appel API ressemble alors à une requête non authentifiée et est rejeté comme « unauthorised ».
- Échec de la vérification Origin/Referrer. Si le backend valide que les requêtes proviennent de paratext.org lui-même (une mesure anti-abus légère courante au lieu d'une authentification réelle), tout ce qui modifie la façon dont la page est chargée — un filtre web/proxy d'entreprise qui réécrit ou supprime les en-têtes, un proxy de traduction, le « mode lecture », ou l'ouverture du lien dans le navigateur intégré d'une autre application — peut faire échouer cette vérification, même si la page s'affiche correctement.
- Proxy d'entreprise/inspection SSL supprimant les en-têtes. Les collègues affiliés à SIL sont souvent sur des réseaux gérés avec une inspection approfondie des paquets ou un filtrage de contenu qui supprime les en-têtes Authorization, Cookie ou personnalisés sur les appels API sortants, tandis que l'interface de chat elle-même se charge normalement depuis un CDN.
- Clé API backend partagée atteignant une limite de débit/quota. Si le widget fait un proxy vers une API comme celle de Claude en utilisant une clé serveur partagée, une rafale de trafic de démonstration simultané (vous + 3 collègues envoyant des prompts dans la même minute) pourrait déclencher une limite de débit que le backend signale comme « unauthorised » plutôt que « too many requests ».
Le moyen le plus rapide de confirmer : demander à un collègue d'ouvrir les DevTools du navigateur → onglet Network, de réessayer un prompt, de cliquer sur la requête échouée et de vérifier le code de statut HTTP réel (401 vs 403 vs 429) et le corps de la réponse — cela nous dira définitivement laquelle de ces causes est en jeu. Si vous pouvez obtenir cela, je pourrai identifier précisément la cause.
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.
Traduit automatiquement depuis English
