Add a dangerouslyAllowBrowser option to allow running in the browser #248
Comments
Note that it doesn't actually work yet because of anthropics/anthropic-sdk-typescript#248, anthropic doesn't allow running in the browser. But hte machinery is useful for other providers at least... It's effectively disabled and hidden in the UI currently. Merge branch 'anthropic' * anthropic: (26 commits) Make it so Anthropic is hidden from the dialog to start because it doesn't yet run in browser. Make it so other providers are hidden. Skip empty chunks in conversationTurn. SET_API_KEY --> SET_API_KEYS. Tweak a weird race issue in sprout-view. Fixed a bug where if you had api keys for two providers set it would double run a sprout. Make it so if a sprout already has finish(), then streamWillStart will call stopStreaming immediately. Make the submit button force close the dialog too. Update the model requirements updating to be a subset of the modelProvider that has explicitly or implicitly already been set. AIProvider's methods override the modelRequirements to add the subset of models we actually have keys for. modelMatches allows specifying modelProvider, a single item or an array. Fix a bug introduced in bac7ad3 where the api key isn't persisted to local storage. Allow forcing open the API keys dialog. Fix a serious bug / infinite loop when setting an API key introduced in bac7ad3 Render controls for multiple api key providers in the dialog. Fixed a bug where selectAPIKeysDialogAutoOpen logic was backwards. wire in apikeys to dialog. Wire in the notion of forcing open API key dialog. A layer of indirection of whether to open the apikeys dialog. sprout-view behavior stores and handles all kinds of APIKeys now. ...
|
Unfortunately Anthropic continues to have no plans to change this. We'll be sure to update the issues here if & when this changes. |
|
I also need this dangerouslyAllowBrowser thing. Many developers and customers need it, as can be seen in many forums and discussions. I really can't find logic in Anthropic's decision to reject feature that so many people ask for. |
|
My main goals:
Of course, inserting the api key into the browser is not safe, but maybe it is possible to do something like OAuth authorization? |
Now talks to the Anthropic API directly using their new anthropic-dangerous-direct-browser-access: true header. Also shows a "Generating..." message. Code change mostly by Claude: https://gist.github.com/simonw/6ff7bc0d47575a53463abc3482608f74
|
Blogged about this here: https://simonwillison.net/2024/Aug/23/anthropic-dangerous-direct-browser-access/ |
|
Amazing, thank you @simonw! Note btw that using import Anthropic from '@anthropic-ai/sdk';
const client = new Anthropic({
apiKey: null,
dangerouslyAllowBrowser: true
}); |
|
II'm facing the same problem, my open source interface doesn't work for Anthropic due to this error. |
I know that #28 and #219 were both closed as not planned.
In many cases it doesn't make sense to call directly from a browser environment because it could expose the secret API key.
However there are some valid use cases, especially adjacent to open source and tinkerers, where a "BYOKey" pattern makes sense. This happens when for example the project is open source, and the creator cannot and should not pay for API use on behalf of users. The user wouldn't want to give their API key directly to the creator of the service to be passed with a proxy, because who knows what the proxy is doing with that key. In this limited case, it makes sense for the webapp be constructed to store the users' API key in localStorage and only send it directly to Anthropic. This kind of set up allows a lot more tinkering-style apps to be built that cannot handle the marginal costs of completions on behalf of their users.
For example, I have built https://github.com/jkomoros/code-sprouts to support OpenAI, but also want to extend it to support Anthropic too.
Obviously, this is a potential footgun if used insecurely.
OpenAI has resolved this issue by having a
dangerouslyAllowBrowserkey that must be provided to run in a browser context. Something like that could allow this use case while minimizing potential misuse.The text was updated successfully, but these errors were encountered: