Are we talking about flickr/23? While I agree that protecting your secret is hard (impossible) I don't believe that really exposes you to impersonation. In order to impersonate you, the token which you get back after authentication would also need to be stolen, and you can throw that away when your extension closes. This will force the user (or impersonator) to re-authenticate every time they need to use the protected methods.
If a user sees the flickr authentication window for your extension when they are using another product that should be enough warning, no? Other than that, I'd agree that obfuscation seems like your only solution, as any thing else (proxy etc.) is really just changing to another secret, which you will have the same issues with. Adam On 25/05/06, Brian King <[EMAIL PROTECTED]> wrote:
I have an extension that implements a public API which needs to have an API key and a shared secret. Each user must give the extension permission to access their data on this public service. The problem is that, as a javascript application, our shared secret will be in clear view in the deployed code. This means that, potentially, anyone can write their own application with our shared secret and pretend to be us, accessing user data with the same permissions that the user gave us. The options are: 1. Leave secret key in the code. This is easiest solution, but clearly undesirable, for the reason above. 2. Ask each user to register their own key and specify that for their local copy. This is not a ideal solution because it presents such a big hurdle to non-technical or casual users. 3. Proxy. Shared secret is stored on a server somewhere. The extension sends all API requests through that server, which then signs the requests with the keys. This requires some service on some server to be always available. If the extension became popular, this might not scale plus it adds an extra request level and delay for each operation. 4. XPCOM. We could 'hide' our secret key in a small, compiled XPCOM component, and keep the source secret. This would disguise our shared secret to casual snoopers. Although it may be possible to reverse engineer this component. Anyone else run into a similar issue and find a decent solution? -- Brian King www.mozdev.org - free project hosting for the Mozilla community _______________________________________________ Project_owners mailing list [email protected] http://mozdev.org/mailman/listinfo/project_owners
_______________________________________________ Project_owners mailing list [email protected] http://mozdev.org/mailman/listinfo/project_owners
