49

对于一个宠物项目，我开发了一个桌面应用程序，它需要来自多个不同 Web 服务的 API 密钥。

我一直在研究并准备这个应用程序成为开源的，并且遇到了如何处理这些密钥的问题。

问题是这样的：我的理解是，使用应用程序或查看/修改源代码的任何人都不应看到这些 API 密钥。在 Web 服务端，这些 API 密钥用于识别访问其 API 的应用程序，并酌情允许/阻止使用。在大多数接收这些密钥的 TOS 中，实际上明确规定不得与世界共享密钥。

目前我所有的密钥都是硬编码的，但在如何处理开源应用程序中的私钥情况方面，我陷入了僵局：

- 如果密钥仍然是硬编码的，一旦我的源代码出现，它们就会公开可见。

-我不能真正从代码分发中省略带有密钥的源文件，因为那样它就不会编译。这在技术上解决了问题，但引入了一个新的、不可接受的问题。

- 如果我将密钥推送到 .ini 或其他配置文件，并且根本不将该文件包含在我的公共代码存储库中，它仍然必须与我的应用程序的二进制文件一起分发才能使应用程序运行，所以我的密钥将在应用程序分发而不是源代码分发中可见。不是改进。我试图在这个 INI 文件上使用的任何加密操作都会增加任何试图修改我的代码的人的复杂性。

那么，关于我的代码库（目前在 Mercurial 下进行版本控制），管理所有内容以便代码可以公开但我的密钥保持私有的最佳方式是什么？

4

2 回答 2

19

不知道您使用的是什么语言，但例如在 C/C++ 中，您将添加一个包含 API 密钥的包含文件，然后将其排除在源代码控制之外，而是添加一个带有显式伪造API 密钥的伪造文件。大多数语言都有一种或另一种方式来包含文件。

于 2009-12-31T05:04:36.523 回答
8

您的应用应使用配置文件。此配置文件在运行时加载，不应影响编译。允许用户下载二进制文件并仍然使用他们自己的 api 密钥。

正如 Kornel 所说，您可以在源代码管理中包含一个带有伪造 API 密钥的示例配置文件。

另一种选择是，您可以与运行 Web 服务的人员交谈并要求两件事中的一件。

  1. 一个临时密钥，仅适用于有限的功能。这会让用户看到你的应用程序的基本功能，但有些人永远不会更新密钥，只使用基本的东西。

  2. 与网络服务交谈，看看他们是否会为您的应用程序提供一个特殊的 API 密钥。开源版本将要求用户输入自己的。但是您的二进制文件可以使用标准的二进制文件。

为 api 密钥使用配置的想法并不新鲜或闻所未闻。Bit.ly 服务做到了。我看到的所有与 Bit.ly 一起使用的开源应用程序都要求您提供用户名和 api 密钥，然后才能使用它。

这没有什么不同？

于 2009-12-31T05:15:23.830 回答