Claude API, CORS desteğini başlattı; istemci taraflı uygulamalar artık mümkün

• Anthropic, JSON API için CORS desteğini etkinleştirdi
  • Bu da artık kullanıcının tarayıcısından doğrudan Claude LLM çağrısı yapılabileceği anlamına geliyor
• Bu özellik, "anthropic-sdk-typescript: add support for browser usage" PR'ında gizliydi
  • İncelendiğinde, ilgili koda yönelik Anthropic TypeScript SDK değişiklikleri yeni JSON API özelliğini ortaya koyuyor
• Aşağıdaki HTTP istek başlığı eklenerek Anthropic API için CORS desteği etkinleştirilebiliyor:
  anthropic-dangerous-direct-browser-access: true
• Bu başlık eklendiğinde tarayıcıdan doğrudan Anthropic modellerine çağrı yapılabiliyor
• API anahtarı istemci koduna gömülürse, siteye erişebilen kullanıcılar bu API anahtarını çalıp onun yerine istek gönderebileceği için Anthropic bu özelliği eklemeye isteksizdi
• Buna rağmen bu özellik için birkaç makul kullanım senaryosu var
  • Güvenilir kullanıcılara açık şirket içi araçlar için uygun olabilir
  • Ya da kullanıcıların istemci taraflı uygulamada kullanmak üzere kendi anahtarlarını sağladığı "BYOK(Bring Your Own Key)" desenini uygulamak mümkün

Haiku - istemci taraflı uygulama örneği

• Hızlıca hazırlanmış Haiku sayfası, CORS desteği gerektiren istemci taraflı bir uygulama örneği
• Web kamerasına erişim istiyor, ardından Anthropic API anahtarını istiyor (tarayıcının localStorage alanında saklıyor), sonra fotoğraf çekip Haiku modelini kullanarak bunu bir haikuya dönüştüren basit bir uygulama
• Daha önce Vercel üzerinde kendi proxy'sini çalıştırarak Anthropic API'ye CORS desteği eklemek gerekiyordu
• Artık uygulama yeni başlığı gönderecek şekilde güncellendi ve proxy olmadan doğrudan Anthropic ile iletişim kurabiliyor

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 görüşleri

• Kişisel olarak kullanıcıların kendi anahtarlarını getirdiği web uygulamaları yapmayı seviyorum

  • Bu yaklaşım, çalıştırılabilir dosya dağıtımının rahatlığını açık kaynak avantajlarıyla birleştiriyor
  • Bu şekilde iki web uygulaması geliştirdim
    • Mikrofon girdisi kullanan gerçek zamanlı transkripsiyon ve çeviri uygulaması
    • SRT altyazılarını çeşitli dillere çeviren uygulama
  • "Kullanıcı kendi anahtarını getirir" modelini seçmemin iki temel nedeni var
    • Düşük bakım yükü: Zaten çok fazla yazılımın bakımını yapıyorum, yan projelerin bakımını da üstlenmek istemiyorum
    • Düşük maliyet: Uygulamayı reklamsız dağıtabilir ve işletme maliyetlerini düşük tutabilirim
  • Böylece bakım yükünü ve kullanıcı maliyetini en aza indirirken faydalı araçlar üretip paylaşabiliyorum

• Kullanıcıların kendi anahtarlarını getirdiği durumlarda bu sorun olmaz

  • İşlem istemci tarafında gerçekleşir ve cihaz ya da web sitesi ele geçirilmediği sürece sorun yoktur
  • Ancak geliştirici üretim anahtarlarını istemci tarafında kullanırsa saldırı yüzeyi artabilir
  • Kolaylık ve performans uğruna güvenlik değerlendirmesi yapmadan bunu uygulayabilirler

• Neden JWT desteklenmediğini anlamıyorum

  • Supabase, güvenli istemci tarafı erişimine iyi bir örnek

• Anthropic ve tüm yapay zeka sağlayıcıları "Login with ___" özelliğini hayata geçirmeli

  • Kullanıcıların kendi yapay zeka kaynaklarına güvenli şekilde erişebilmesi sağlanmalı
  • Çoğu kullanıcı API anahtarı oluşturup yüklemeyi uğraştırıcı buluyor ve bunu güvenli şekilde yönetemiyor

• Kullanıcıların kendi anahtarlarını getirdiği durumda OAuth daha iyi bir çözüm

  • Bazı geliştiriciler gerçek anahtarı frontend'e hardcode edip sorun yaşayabilir
  • OAuth daha güvenli bir çözüm

• İç geliştirme için uygun olabilir ama son kullanıcıya yönelik uygulamalar için uygun değil