Claude API เริ่มรองรับ CORS ทำให้แอปพลิเคชันฝั่งไคลเอนต์ใช้งานได้

 (simonwillison.net)
7 คะแนน โดย xguru 2024-08-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Anthropic เปิดใช้งานการรองรับ CORS สำหรับ JSON API แล้ว
    • นั่นหมายความว่าตอนนี้สามารถเรียกใช้ Claude LLM ได้โดยตรงจากเบราว์เซอร์ของผู้ใช้
  • ฟีเจอร์นี้ซ่อนอยู่ใน PR ชื่อ "anthropic-sdk-typescript: add support for browser usage"
    • เมื่อลองไล่ดู พบว่าการเปลี่ยนแปลงใน Anthropic TypeScript SDK สำหรับโค้ดดังกล่าวแสดงให้เห็นฟีเจอร์ใหม่ของ JSON API
  • สามารถเปิดใช้การรองรับ CORS สำหรับ Anthropic API ได้โดยเพิ่ม HTTP request header ต่อไปนี้:
    anthropic-dangerous-direct-browser-access: true
  • เมื่อเพิ่ม header นี้ ก็จะสามารถเรียกใช้โมเดลของ Anthropic ได้โดยตรงจากเบราว์เซอร์
  • Anthropic เคยลังเลที่จะเพิ่มฟีเจอร์นี้ เพราะหากใส่ API key ไว้ในโค้ดฝั่งไคลเอนต์ ผู้ใช้ที่เข้าถึงเว็บไซต์นั้นได้ก็อาจขโมย API key ไปใช้ส่งคำขอแทนได้
  • ถึงอย่างนั้น ก็ยังมี use case ที่เหมาะสมสำหรับฟีเจอร์นี้อยู่บ้าง
    • ใช้ได้ดีกับเครื่องมือภายในบริษัทที่เปิดให้ผู้ใช้ที่เชื่อถือได้
    • หรืออาจใช้รูปแบบ "BYOK (Bring Your Own Key)" ที่ให้ผู้ใช้ใส่คีย์ของตนเองเพื่อใช้งานในแอปฝั่งไคลเอนต์ก็ได้

Haiku - ตัวอย่างแอปฝั่งไคลเอนต์

  • หน้า Haiku ที่ทำขึ้นแบบง่าย ๆ เป็นตัวอย่างของแอปฝั่งไคลเอนต์ที่ต้องการการรองรับ CORS
  • เป็นแอปง่าย ๆ ที่ขอสิทธิ์เข้าถึงเว็บแคม ขอ Anthropic API key (แล้วเก็บไว้ใน localStorage ของเบราว์เซอร์) จากนั้นถ่ายภาพและใช้โมเดล Haiku เปลี่ยนภาพนั้นให้เป็นไฮกุ
  • ก่อนหน้านี้จำเป็นต้องรันพร็อกซีของตัวเองบน Vercel เพื่อเพิ่มการรองรับ CORS ให้กับ Anthropic API
  • ตอนนี้ได้อัปเกรดแอปให้ส่ง header ใหม่นี้แล้ว และสามารถสื่อสารกับ 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);  
  });

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
xguru 2024-08-24

ความคิดเห็นจาก Hacker News

  • โดยส่วนตัวชอบทำเว็บแอปที่ให้ผู้ใช้นำคีย์ของตัวเองมาใช้

    • แนวทางนี้ผสานความสะดวกในการแจกจ่ายแบบไฟล์รันได้เข้ากับข้อดีของโอเพนซอร์ส
    • เคยพัฒนาเว็บแอปแบบนี้มาแล้วสองตัว
      • แอปถอดเสียงและแปลภาษาแบบเรียลไทม์ที่ใช้ไมโครโฟนเป็นอินพุต
      • แอปแปลซับไตเติล SRT เป็นหลายภาษา
    • มีเหตุผลหลักสองข้อที่เลือกโมเดล "ให้ผู้ใช้นำคีย์มาเอง"
      • ดูแลรักษาน้อย: ผมต้องดูแลซอฟต์แวร์หลายตัวอยู่แล้ว จึงไม่อยากต้องมาดูแลโปรเจกต์ข้างเคียงอีก
      • ต้นทุนต่ำ: สามารถปล่อยแอปได้โดยไม่ต้องมีโฆษณา และลดต้นทุนการดำเนินงานได้
    • จึงสามารถสร้างและแชร์เครื่องมือที่มีประโยชน์ได้ โดยลดภาระการดูแลรักษาและค่าใช้จ่ายของผู้ใช้ให้น้อยที่สุด

  • ในกรณีที่ผู้ใช้นำคีย์ของตัวเองมาใช้ ก็ไม่ใช่ปัญหา

    • งานทั้งหมดเกิดขึ้นฝั่งไคลเอนต์ และตราบใดที่อุปกรณ์หรือเว็บไซต์ไม่ถูกเจาะ ก็ถือว่าโอเค
    • แต่ถ้านักพัฒนาเอาคีย์โปรดักชันไปใช้ฝั่งไคลเอนต์ พื้นผิวการโจมตีก็อาจเพิ่มขึ้น
    • อาจมีคนทำแบบนี้เพราะความสะดวกและประสิทธิภาพ โดยไม่ได้คำนึงถึงเรื่องความปลอดภัย

  • ไม่เข้าใจว่าทำไมถึงไม่รองรับ JWT

    • Supabase เป็นตัวอย่างที่ดีของการให้เข้าถึงฝั่งไคลเอนต์อย่างปลอดภัย

  • Anthropic และผู้ให้บริการ AI ทุกรายควรทำฟีเจอร์ "Login with ___"

    • เพื่อให้ผู้ใช้สามารถไว้วางใจการใช้ทรัพยากร AI ของตัวเองได้
    • ผู้ใช้ส่วนใหญ่จะมองว่าการสร้างและโหลด API key เป็นเรื่องยุ่งยาก และก็จัดการให้ปลอดภัยได้ไม่ดี

  • ถ้าผู้ใช้นำคีย์ของตัวเองมาใช้ OAuth เป็นทางออกที่ดีกว่า

    • นักพัฒนาบางคนอาจฮาร์ดโค้ดคีย์จริงไว้ในฟรอนต์เอนด์แล้วเจอปัญหาตามมา
    • OAuth เป็นทางเลือกที่ปลอดภัยกว่า

  • อาจเหมาะกับการพัฒนาภายในองค์กร แต่ไม่เหมาะกับแอปที่ทำให้ผู้ใช้ทั่วไป