Claude's API now supports CORS requests, enabling client-side applications
1–10 of 173 posts
Re: Claude's API now supports CORS requests, enabling client-side applications
#2Maybe for internal development, but definitely not for a user-facing app. Making less impactful of a change. But still nice
Re: Claude's API now supports CORS requests, enabling client-side applications
#3Maybe for internal development, but definitely not for a user-facing app. Making less impactful of a change. But still nice
I'm thinking it enables apps where users can bring their own keys without exposing it to my server.
Re: Claude's API now supports CORS requests, enabling client-side applications
#4The "dangerous" part of "anthropic-dangerous-direct-browser-access" is because you should never expose API keys in client code.
Re: Claude's API now supports CORS requests, enabling client-side applications
#5Maybe for internal development, but definitely not for a user-facing app. Making less impactful of a change. But still nice
I'm thinking it enables apps where users can bring their own keys without exposing it to my server.
That's what I've done for my chatgpt UI - I store the API key and any other user config in local storage.
Re: Claude's API now supports CORS requests, enabling client-side applications
#6The "dangerous" part of "anthropic-dangerous-direct-browser-access" is because you should never expose API keys in client code.
Unless it's the client's keys.
Or keys obtained on the client's behalf.
Re: Claude's API now supports CORS requests, enabling client-side applications
#7Maybe for internal development, but definitely not for a user-facing app. Making less impactful of a change. But still nice
I'm thinking it enables apps where users can bring their own keys without exposing it to my server.
That's the only good use of this but I bet people will end up leaking their keys being stupid with it.
Re: Claude's API now supports CORS requests, enabling client-side applications
#8The "dangerous" part of "anthropic-dangerous-direct-browser-access" is because you should never expose API keys in client code.
Unless it's the client's keys. Or keys obtained on the client's behalf.
Even using the client's keys it would be a good idea to give a disclaimer that their key may be stored (If that is the case) and can be accessible through nefarious means. People are very susceptible to phishing attempts etc. and this sort of business model (where you have the client supply the key and store it through the browser is a slippery slope.
Re: Claude's API now supports CORS requests, enabling client-side applications
#9> I must strongly advise against making direct API calls from a browser, as it exposes your API key and violates best practices for API security.
Hilarious that even the LLM warned against this
Re: Claude's API now supports CORS requests, enabling client-side applications
#10I love making web apps where users bring their own keys. This approach combines the best of both worlds: the convenience of distributing executable files and the benefits of open source. So far, I have developed two web apps:
1. A live transcription and translation app that uses microphone input. This is useful for watching proprietary content and facilitating communication.
2. An app that translates SRT subtitles into various languages.
I opt for the "bring your own keys" model for two main reasons:
1. Low maintenance: As a professional software developer, I already maintain a lot of software, and the last thing I want is to maintain my side projects. My goal is to write and distribute these apps so they continue working without requiring constant attention from me.
2. Low cost: This model allows me to distribute the apps without ads. By having users provide their own keys, I can keep operational costs down and avoid the need for monetization through advertising.
This approach enables me to create and share useful tools while keeping both my maintenance burden and user costs to a minimum.