Claude API mulai mendukung CORS, memungkinkan aplikasi sisi klien

• Anthropic telah mengaktifkan dukungan CORS untuk JSON API mereka
  • Artinya, kini Claude LLM bisa dipanggil langsung dari browser pengguna
• Fitur ini tersembunyi di PR "anthropic-sdk-typescript: add support for browser usage"
  • Setelah ditelusuri, perubahan pada Anthropic TypeScript SDK untuk kode tersebut memperlihatkan fitur baru di JSON API
• Dukungan CORS untuk Anthropic API bisa diaktifkan dengan menambahkan header permintaan HTTP berikut:
  anthropic-dangerous-direct-browser-access: true
• Dengan menambahkan header ini, pemanggilan ke model Anthropic bisa dilakukan langsung dari browser
• Anthropic selama ini enggan menambahkan fitur ini karena jika API key dimasukkan ke dalam kode klien, siapa pun yang memiliki akses ke situs tersebut bisa mencuri API key dan menggunakannya untuk membuat permintaan atas nama pengguna
• Meski begitu, ada beberapa use case yang cukup masuk akal untuk fitur ini
  • Cocok untuk alat internal perusahaan yang hanya digunakan oleh pengguna tepercaya
  • Atau bisa juga menerapkan pola "BYOK(Bring Your Own Key)" di mana pengguna menyediakan key mereka sendiri untuk dipakai di aplikasi sisi klien

Haiku - contoh aplikasi sisi klien

• Halaman Haiku yang dibuat sederhana ini adalah contoh aplikasi sisi klien yang membutuhkan dukungan CORS
• Aplikasi ini meminta akses ke webcam, lalu meminta Anthropic API key (disimpan di localStorage browser), mengambil foto, dan menggunakan model Haiku untuk mengubahnya menjadi haiku
• Sebelumnya, perlu menjalankan proxy sendiri di Vercel untuk menambahkan dukungan CORS ke Anthropic API
• Sekarang aplikasinya telah diperbarui agar mengirim header baru tersebut, dan bisa berkomunikasi langsung dengan Anthropic tanpa 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]

Komentar Hacker News

• Secara pribadi saya suka membuat aplikasi web yang meminta pengguna membawa kunci mereka sendiri

  • Pendekatan ini menggabungkan kemudahan distribusi aplikasi web dengan manfaat open source
  • Saya sudah mengembangkan dua aplikasi web seperti ini
    • Aplikasi transkripsi dan terjemahan real-time yang menggunakan input mikrofon
    • Aplikasi untuk menerjemahkan subtitle SRT ke berbagai bahasa
  • Ada dua alasan utama memilih model "pengguna membawa kunci sendiri"
    • Perawatan rendah: saya sudah memelihara banyak perangkat lunak dan tidak ingin memelihara side project juga
    • Biaya rendah: aplikasi bisa didistribusikan tanpa iklan dan biaya operasional tetap rendah
  • Dengan begitu, saya bisa membuat dan membagikan alat yang berguna sambil meminimalkan beban perawatan dan biaya bagi pengguna

• Dalam situasi di mana pengguna membawa kunci mereka sendiri, ini bukan masalah

  • Pekerjaan dilakukan di sisi klien, dan selama perangkat atau situs web tidak dikompromikan, seharusnya aman
  • Namun, jika pengembang menggunakan production key di sisi klien, permukaan serangan bisa meningkat
  • Ini bisa dilakukan demi kemudahan dan performa tanpa pertimbangan keamanan yang memadai

• Saya tidak mengerti mengapa JWT tidak didukung

  • Supabase adalah contoh yang baik untuk akses sisi klien yang aman

• Anthropic dan semua vendor AI seharusnya mengimplementasikan fitur "Login with ___"

  • Pengguna perlu bisa mempercayakan resource AI mereka sendiri
  • Kebanyakan pengguna merasa repot membuat dan memuat API key, dan juga tidak bisa mengelolanya dengan aman

• Jika pengguna membawa kunci mereka sendiri, OAuth adalah solusi yang lebih baik

  • Beberapa pengembang mungkin akan hardcode kunci yang sebenarnya di frontend lalu mengalami masalah
  • OAuth adalah solusi yang lebih aman

• Mungkin cocok untuk pengembangan internal, tetapi tidak cocok untuk aplikasi yang ditujukan kepada pengguna