Claude API bắt đầu hỗ trợ CORS, mở ra khả năng cho ứng dụng phía client

• Anthropic đã bật hỗ trợ CORS cho JSON API
  • Nghĩa là giờ đây có thể gọi trực tiếp Claude LLM từ trình duyệt của người dùng
• Tính năng này được ẩn trong PR "anthropic-sdk-typescript: add support for browser usage"
  • Khi xem kỹ, các thay đổi trong Anthropic TypeScript SDK cho đoạn mã đó cho thấy một tính năng mới của JSON API
• Có thể kích hoạt hỗ trợ CORS cho Anthropic API bằng cách thêm header HTTP sau:
  anthropic-dangerous-direct-browser-access: true
• Khi thêm header này, có thể gọi trực tiếp các model của Anthropic từ trình duyệt
• Anthropic trước đây do dự trong việc bổ sung tính năng này vì nếu nhúng API key vào mã phía client, bất kỳ ai có thể truy cập trang đó cũng có thể đánh cắp API key và gửi yêu cầu thay bạn
• Dù vậy, vẫn có một số trường hợp sử dụng khá hợp lý cho tính năng này
  • Phù hợp với các công cụ nội bộ của công ty chỉ lộ ra cho những người dùng đáng tin cậy
  • Hoặc cũng có thể triển khai mô hình "BYOK(Bring Your Own Key)", nơi người dùng tự cung cấp key của họ để dùng trong ứng dụng phía client

Haiku - ví dụ ứng dụng phía client

• Trang Haiku được làm nhanh là một ví dụ về ứng dụng phía client cần hỗ trợ CORS
• Đây là một ứng dụng đơn giản: xin quyền truy cập webcam, yêu cầu API key của Anthropic (lưu trong localStorage của trình duyệt), chụp ảnh rồi dùng model Haiku để biến nó thành một bài haiku
• Trước đây phải chạy proxy riêng trên Vercel để thêm hỗ trợ CORS cho Anthropic API
• Giờ đây ứng dụng đã được nâng cấp để gửi header mới, và có thể giao tiếp trực tiếp với Anthropic mà không cần 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]

Ý kiến Hacker News

• Cá nhân tôi thích làm các ứng dụng web nơi người dùng tự mang theo khóa của mình

  • Cách tiếp cận này kết hợp sự tiện lợi của việc phân phối dưới dạng tệp thực thi với lợi ích của mã nguồn mở
  • Tôi đã phát triển hai ứng dụng web như vậy
    • Ứng dụng phiên âm và dịch theo thời gian thực dùng đầu vào micro
    • Ứng dụng dịch phụ đề SRT sang nhiều ngôn ngữ
  • Có hai lý do chính để chọn mô hình "người dùng tự mang khóa"
    • Bảo trì thấp: tôi đang phải bảo trì rất nhiều phần mềm nên không muốn tiếp tục bảo trì các dự án phụ
    • Chi phí thấp: có thể phát hành ứng dụng không cần quảng cáo và giữ chi phí vận hành ở mức thấp
  • Có thể tạo và chia sẻ các công cụ hữu ích trong khi giảm thiểu gánh nặng bảo trì và chi phí cho người dùng

• Trong trường hợp người dùng tự mang khóa của mình thì đây không phải là vấn đề

  • Công việc được thực hiện ở phía client, và miễn là thiết bị hay trang web không bị xâm phạm thì vẫn ổn
  • Tuy nhiên, nếu nhà phát triển dùng khóa production ở phía client thì bề mặt tấn công có thể tăng lên
  • Vì sự tiện lợi và hiệu năng, họ có thể làm điều này mà không cân nhắc đến bảo mật

• Tôi không hiểu vì sao lại không hỗ trợ JWT

  • Supabase là một ví dụ tốt về việc cung cấp quyền truy cập phía client an toàn

• Anthropic và mọi nhà cung cấp AI nên triển khai tính năng "Đăng nhập bằng ___"

  • Cần để người dùng có thể tin tưởng sử dụng tài nguyên AI của chính họ
  • Hầu hết người dùng thấy việc tạo và nạp API key là phiền phức, và cũng không thể quản lý nó một cách an toàn

• Nếu người dùng tự mang khóa của mình thì OAuth là giải pháp tốt hơn

  • Một số nhà phát triển có thể hardcode khóa thật trực tiếp vào frontend rồi gặp rắc rối
  • OAuth là giải pháp an toàn hơn

• Có thể phù hợp cho phát triển nội bộ, nhưng không phù hợp cho ứng dụng hướng tới người dùng