-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How bad is it if my apiSecret is not so secret? #11
Comments
I've pondered this myself, with no good conclusion yet. It seems unavoidable for a no-server app. My best advice currently, would be to use a proper User-Agent header, and make sure you aren't exposing a read-write key. The keys serve two functions at present. As a way to pinpoint something abusive and kill it. And, to restrict functionality with permission levels, like write access. When talking about read-only keys, it's not hurting us really. It's just the risk that if someone started hammering the API with your key and we block it, it would hurt you by accident. This is a good question for the larger group, since it's a "problem" I'd like a solution for. I'll leave this issue open for a while, if anyone wants to chime in. I'm open to any ideas... |
Related issue: How if I am developing a self-hosted open source podcast player? It seems silly to me to ask users to set up their own API key. Possible issues with including a read-only API key in the (open) source code are, as you mention, someone taking that key and starting to hammer the API resulting in you guys blocking the key. Honestly, I don't see why anyone would do that, except as a way to annoy users of my app (which are none at the moment), but it does seem like a potential issue and it would be nice to have a way to deal with it. Anyway, no big deal, I guess, but I thought I'll mention it here. |
Yeah, it’s still an issue really. I’m open to any ideas you might have. |
Would it be possible to include in apps/software a system that automatically requests and gets assigned a read-only API secret? It could be stored in the app/software and reused. That secret could have a special status so it gets deleted e.g. 12 months after not being used (or 24 months after creation) to keep the key list somewhat clean. (As it's assigned per-user, it wouldn't be good for privacy per se, but I guess it's acceptable.) Btw I believe that for AntennaPod the secret is hard-coded for free builds so that F-Droid can pick it up (not sure about this one). And we have not yet had to rest the secrets because of misuse. |
Yes I think that’s a good way to go. I’m ok with building that. I’ll ping here when it’s ready. Give me some time, I’m pretty backed up atm. |
Hi all,
I am a developer of a browser extension to subscribe and listen to podcasts (https://github.com/podStation/podStation).
As it is a client side application, the API secret would be exposed to people using the software (could be obfuscated, but not really secret).
How bad is it to disclose the API secret?
Best Regards,
Guilherme.
The text was updated successfully, but these errors were encountered: