Hi, In Skrooge, we have a plugin to download prices from coinmarketcap. For that, an API key is needed. We decided that: If the end user wants to use this plugin, he will have to request a personal API key and store it in Skrooge that will use it to call the service. By doing like that, we don't need to store the API key in a public area. In fact, each user has its own key.
Regards. Le 18/01/2021 à 17:28, Thomas Baumgart a écrit : > On Montag, 18. Januar 2021 17:20:31 CET Volker Krause wrote: > >> On Montag, 18. Januar 2021 12:21:30 CET Jean-Baptiste Mardelle wrote: >>> Hi all, >>> >>> For Kdenlive, we are planning to expand the use of online services to >>> download ambiance music or videos for use in personal projects. To this >>> purpose, most online services provide us an API key that is used to >>> identify our app (Kdenlive) when querying their API. >>> >>> Does anyone have experience / advice on how to protect these API keys so >>> that they are not publicly available ? Is there any KDE online service or >>> framework helping to achieve that ? >> We have a similar problem in KPublicTransport. As others said, I don't think >> keeping API keys secret is possible, they need to be handed out to the user >> eventually after all. This already doesn't really work for closed-source >> applications, and open source certainly doesn't make that any easier. >> >> Terms of services requiring protection of API keys are IMHO therefore mostly >> wishful thinking. I have talked to the providers of two of the backends we >> use >> in KPublicTransport about this, they understand the problem and are ok with >> having the API keys in public source code. That might be the more realistic >> approach. > It's what I did in the context of KMyMoney and HBCI online access. It's not > strictly an API key but only used as identifier for the application, but > nevertheless that number is in the KDE repos after I have confirmed that it > is OK. >
