Claude API ने CORS सपोर्ट शुरू किया, जिससे client-side applications संभव हुईं

• Anthropic ने JSON API के लिए CORS सपोर्ट सक्षम कर दिया है
  • यानी अब यूज़र के ब्राउज़र से सीधे Claude LLM को कॉल किया जा सकता है
• यह फीचर "anthropic-sdk-typescript: add support for browser usage" PR में छिपा हुआ है
  • खोजबीन करने पर, उस कोड के लिए Anthropic TypeScript SDK में किए गए बदलाव एक नई JSON API क्षमता दिखाते हैं
• नीचे दिया गया HTTP request header जोड़कर Anthropic API के लिए CORS सपोर्ट सक्षम किया जा सकता है:
  anthropic-dangerous-direct-browser-access: true
• इस header को जोड़ने पर ब्राउज़र से सीधे Anthropic models को कॉल किया जा सकता है
• Anthropic अब तक इस फीचर को जोड़ने में हिचकिचाता रहा था, क्योंकि अगर API key को client code में शामिल किया जाए, तो उस साइट तक पहुँच रखने वाले यूज़र API key चुरा सकते हैं और उसकी ओर से requests कर सकते हैं
• फिर भी, इस फीचर के कुछ अच्छे use cases हैं
  • भरोसेमंद यूज़र्स के लिए उपलब्ध कंपनी के internal tools में यह ठीक है
  • या फिर "BYOK(Bring Your Own Key)" pattern लागू किया जा सकता है, जिसमें यूज़र client-side app में इस्तेमाल के लिए अपनी key देते हैं

Haiku - client-side app उदाहरण

• जल्दी से बनाई गई Haiku page, CORS सपोर्ट की ज़रूरत वाली client-side app का एक उदाहरण है
• यह एक सरल app है जो webcam access माँगती है, फिर Anthropic API key माँगती है (और उसे ब्राउज़र के localStorage में स्टोर करती है), फोटो लेती है, और Haiku model का उपयोग करके उसे हाइकू में बदल देती है
• पहले इसके लिए Vercel पर अपना proxy चलाना पड़ता था ताकि Anthropic API में CORS सपोर्ट जोड़ा जा सके
• अब app को नया header भेजने के लिए upgrade कर दिया गया है, और यह proxy के बिना सीधे Anthropic से बात कर सकती है

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]

Hacker News राय

• व्यक्तिगत रूप से मुझे ऐसे web app बनाना पसंद हैं जहाँ उपयोगकर्ता अपनी खुद की key लाते हैं

  • यह तरीका executable distribution की सुविधा और open source के फायदों को जोड़ता है
  • मैंने ऐसे दो web app बनाए हैं
    • mic input का उपयोग करने वाला real-time transcription और translation app
    • SRT subtitles को कई भाषाओं में translate करने वाला app
  • "अपनी key लाओ" मॉडल चुनने के दो मुख्य कारण
    • कम maintenance: मैं पहले से बहुत सारा software maintain कर रहा हूँ, इसलिए side project को maintain नहीं करना चाहता
    • कम लागत: app को ads के बिना deploy किया जा सकता है, और operating cost कम रखी जा सकती है
  • maintenance का बोझ और user cost को न्यूनतम रखते हुए उपयोगी tools बनाए और साझा किए जा सकते हैं

• जब उपयोगकर्ता अपनी खुद की key लाते हैं, तब यह समस्या नहीं बनती

  • काम client side पर होता है, और जब तक device या website compromise न हो, तब तक यह ठीक है
  • लेकिन अगर developer production key को client side पर इस्तेमाल करता है, तो attack surface बढ़ सकता है
  • सुविधा और performance के लिए, security पर विचार किए बिना ऐसा किया जा सकता है

• समझ नहीं आता कि JWT support क्यों नहीं है

  • Supabase सुरक्षित client-side access देने का एक अच्छा उदाहरण है

• Anthropic और सभी AI vendors को "Login with ___" feature implement करना चाहिए

  • इससे उपयोगकर्ता अपने AI resources पर भरोसा कर सकेंगे
  • ज़्यादातर उपयोगकर्ताओं के लिए API key बनाना और लोड करना झंझट भरा होता है, और वे इसे सुरक्षित रूप से manage भी नहीं कर पाते

• अगर उपयोगकर्ता अपनी खुद की key लाते हैं, तो OAuth बेहतर solution है

  • कुछ developers असली key को frontend में hardcode कर सकते हैं और फिर मुश्किल में पड़ सकते हैं
  • OAuth अधिक सुरक्षित solution है

• internal development के लिए यह ठीक हो सकता है, लेकिन user-facing apps के लिए उपयुक्त नहीं है