Как открыть исходный код приложения, использующего ключи API [закрыто]
Для проекта pet я разрабатываю настольное приложение, которое требует ключей API от нескольких различных веб-сервисов.
Я просматривал и готовил это приложение, чтобы стать открытым исходным кодом и столкнуться с проблемой, что делать с этими ключами.
Проблема заключается в следующем: я понимаю, что эти ключи API не должны быть видны никому, использующему приложение или просматривающему / изменяющему исходный код. С конца веб-сервиса эти API-ключи используются для идентификации приложения, обращающиеся к своему API, и разрешают/блокируют использование по мере необходимости. В большинстве TOS для получения этих ключей фактически прямо указано, что ключи не должны быть совместно использованы с миром.
В настоящее время все мои ключи жестко закодированы, но я нахожусь в тупике относительно того, как справиться с ситуацией закрытых ключей в приложении с открытым исходным кодом:
- если ключи остаются жестко закодированными, они будут публично видны, как только появится мой исходный код.
- я действительно не могу опустить источник файл с ключами от дистрибутива кода, с тех пор
он не будет компилироваться. Это технически решает проблему, но вводит новую, неприемлемую
один.
- Если я нажму клавиши на a .ini или другой конфигурационный файл, и просто не включать этот файл
в моем публичном репозитории кода он все равно должен быть распространен с двоичным кодом моего приложения, чтобы приложение функционировало, поэтому мои ключи будут видны в дистрибутиве приложения, а не в исходном дистрибутиве. Не улучшение. Любая гимнастика шифрования, которую я попытался использовать в этом файле INI, добавила бы сложности для любого, кто пытается изменить мой код.
Итак, что касается моей кодовой базы (в настоящее время находящейся под контролем Mercurial для контроля версий), как лучше всего управлять всем, чтобы код мог быть открытым, но мои ключи оставались закрытыми?
2 ответов:
Не знаю, какой язык вы используете, но, например, в C/C++ вы добавляете файл include с ключами API, а затем оставляете его вне системы управления версиями, вместо этого добавляете поддельный файл с явно поддельными ключами API. Большинство языков имеют тот или иной способ включения файлов.
Ваше приложение должно использовать конфигурационный файл. Этот конфигурационный файл загружается во время выполнения и не должен влиять на компиляцию. Позволяет пользователям загружать двоичный файл и по-прежнему использовать свой собственный ключ api.
Как говорит Корнель, вы можете включить пример конфигурационного файла с поддельным ключом API в систему управления версиями.
Еще один вариант, вы можете поговорить с людьми, работающими на веб-сервисах, и попросить одну из двух вещей.
Временный ключ, который работает только для ограниченной функциональности. Это было бы пусть пользователи видят основные функции вашего приложения, но некоторые люди никогда не обновляют ключ и просто используют основные вещи.
Поговорите с веб-сервисами, чтобы узнать, дадут ли они вам специальный API-ключ для вашего приложения. Версия с открытым исходным кодом потребует, чтобы пользователи вводили свои собственные. Но ваш двоичный файл может использовать стандартный.
Мысль об использовании конфигурации для ключей api не является новой или неслыханной. Bit.ly это делают службы. И все приложения с открытым исходным кодом я смотрите, что обеспечивают использование с Bit.ly попросите ваше имя пользователя и ключ api, прежде чем вы сможете его использовать.
Это ничем не отличается?
Comments