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