L’API Claude commence à prendre en charge CORS, rendant possibles les applications côté client

• Anthropic a activé la prise en charge de CORS pour son API JSON
  • Cela signifie qu’il est désormais possible d’appeler directement le LLM Claude depuis le navigateur de l’utilisateur
• Cette fonctionnalité est cachée dans la PR « anthropic-sdk-typescript: add support for browser usage »
  • En creusant, les modifications apportées au SDK TypeScript d’Anthropic pour ce code révèlent une nouvelle capacité de l’API JSON
• Il est possible d’activer la prise en charge de CORS pour l’API Anthropic en ajoutant l’en-tête HTTP suivant :
  anthropic-dangerous-direct-browser-access: true
• En ajoutant cet en-tête, il devient possible d’effectuer des appels directs aux modèles Anthropic depuis le navigateur
• Anthropic hésitait à ajouter cette fonctionnalité, car si une clé API est incluse dans le code client, tout utilisateur ayant accès au site peut la voler et envoyer des requêtes à votre place
• Malgré cela, il existe quelques cas d’usage valables pour cette fonctionnalité
  • Elle convient à des outils internes d’entreprise exposés à des utilisateurs de confiance
  • Il est aussi possible de mettre en œuvre un modèle « BYOK (Bring Your Own Key) » dans lequel l’utilisateur fournit sa propre clé pour l’utiliser dans l’application côté client

Haiku - exemple d’application côté client

• La page Haiku créée rapidement est un exemple d’application côté client nécessitant la prise en charge de CORS
• C’est une application simple qui demande l’accès à la webcam, puis une clé API Anthropic (stockée dans le localStorage du navigateur), prend une photo et la transforme en haïku à l’aide du modèle Haiku
• Auparavant, il fallait exécuter son propre proxy sur Vercel pour ajouter la prise en charge de CORS à l’API Anthropic
• L’application a maintenant été mise à jour pour envoyer le nouvel en-tête et peut communiquer directement avec Anthropic, sans proxy

fetch("https://api.anthropic.com/v1/messages";, {  
  method: "POST",  
  headers: {  
    "x-api-key": apiKey,  
    "anthropic-version": "2023-06-01",   
    "content-type": "application/json",  
    "anthropic-dangerous-direct-browser-access": "true",  
  },  
  body: JSON.stringify({  
    model: "claude-3-haiku-20240307",  
    max_tokens: 1024,  
    messages: [  
      {  
        role: "user",  
        content: [  
          { type: "text", text: "Return a haiku about how great pelicans are" },  
        ],  
      },  
    ],  
  }),  
})  
  .then((response) => response.json())  
  .then((data) => {  
    const haiku = data.content[0].text;  
    alert(haiku);  
  });  

[xguru]

Avis sur Hacker News

• Personnellement, j’aime créer des applications web où l’utilisateur apporte sa propre clé

  • Cette approche combine la commodité de la distribution via le web avec les avantages de l’open source
  • J’ai développé deux applications web de ce type
    • une application de transcription et de traduction en temps réel utilisant l’entrée micro
    • une application qui traduit des sous-titres SRT en plusieurs langues
  • Deux raisons principales de choisir le modèle « apportez votre propre clé »
    • Faible maintenance : je maintiens déjà beaucoup de logiciels et je n’ai pas envie de maintenir davantage de side projects
    • Faible coût : je peux distribuer l’application sans publicité et réduire les coûts d’exploitation
  • Cela permet de créer et partager des outils utiles tout en minimisant la charge de maintenance et le coût pour les utilisateurs

• Ce n’est pas un problème quand les utilisateurs apportent leur propre clé

  • Le traitement se fait côté client, donc tant que l’appareil ou le site web n’est pas compromis, ça va
  • En revanche, si un développeur utilise une clé de production côté client, la surface d’attaque peut augmenter
  • Certains peuvent le faire pour des raisons de commodité et de performance, sans assez prendre en compte la sécurité

• Je ne comprends pas pourquoi JWT n’est pas pris en charge

  • Supabase est un bon exemple d’accès sécurisé côté client

• Anthropic et tous les fournisseurs d’IA devraient implémenter une fonction « Login with ___ »

  • Il faut permettre aux utilisateurs de faire confiance à leurs propres ressources IA
  • La plupart des utilisateurs trouvent pénible de générer et charger une clé API, et ne savent pas la gérer en toute sécurité

• Quand les utilisateurs apportent leur propre clé, OAuth est une meilleure solution

  • Certains développeurs risquent de hardcoder la vraie clé dans le frontend et d’avoir des problèmes
  • OAuth est une solution plus sûre

• Cela peut convenir au développement interne, mais pas aux applications destinées aux utilisateurs