Подтвердить что ты не робот

Как открыть приложение, использующее ключи API

Для проекта домашних животных я разрабатываю настольное приложение, которое требует ключей API от нескольких различных веб-сервисов.

Я прошел и подготовил это приложение, чтобы стать открытым исходным кодом и решить проблему с тем, что делать с этими ключами.

Проблема заключается в следующем: я понимаю, что эти ключи API не должны быть видны всем, кто использует приложение, или просматривают/изменяют исходный код. С конца веб-службы эти ключи API используются для идентификации приложений, получающих доступ к их API, и позволяют/блокировать использование по мере необходимости. В большинстве TOS для получения этих ключей он фактически прямо заявил, что ключи не должны использоваться совместно с миром.

В настоящее время все мои ключи жестко закодированы, но я в тупике о том, как обрабатывать ситуацию с закрытыми ключами в приложении с открытым исходным кодом:

-Если ключи остаются жестко закодированными, они будут общедоступны, как только мой исходный код будет.

-Я не могу опустить исходный файл с ключами из дистрибутива кода, так как тогда он не будет компилироваться. Это технически решает проблему, но вводит новую, неприемлемую один.

-Если я выталкиваю ключи в .ini или другой файл конфигурации и просто не включаю этот файл в моем публичном репозитории кода его все равно придется распространять вместе с двоичным кодом моего приложения, чтобы приложение функционировало, поэтому мои ключи будут видны в дистрибутиве приложения вместо исходного. Не улучшение. Любая криптографическая гимнастика, которую я попыталась использовать в этом INI файле, добавила бы сложность для любого, кто пытается изменить мой код.

Итак, что касается моей кодовой базы (в настоящее время под Mercurial для управления версиями), какой лучший способ управлять всем, чтобы код мог быть общедоступным, но мои ключи остаются закрытыми?

4b9b3361

Ответ 1

Не знаю, какой язык вы используете, но, например, в C/С++ вы добавляете файл include с ключами API, а затем оставляете его вне контроля источника, вместо этого добавляете фиктивный файл с явно поддельным API ключи. На большинстве языков есть один или другой способ включения файлов.

Ответ 2

Ваше приложение должно использовать конфигурационный файл. Этот файл конфигурации загружается во время выполнения и не должен влиять на компиляцию. Позволяет пользователям загружать двоичный файл и все еще использовать свой собственный ключ api.

Как говорит Корнель, вы можете включить примерный файл конфигурации с поддельным ключом API в свой исходный элемент управления.

Еще один вариант: вы можете поговорить с людьми, использующими веб-сервисы, и попросить одну из двух вещей.

  • Временный ключ, который работает только для ограниченной функциональности. Это позволит пользователям видеть базовые функции вашего приложения, но некоторые люди никогда не будут обновлять ключ и просто использовать базовый материал.

  • Обратитесь к веб-службам, чтобы узнать, предоставит ли они вам специальный ключ API для вашего приложения. Версия с открытым исходным кодом требует, чтобы пользователи вводили свои собственные. Но ваш двоичный файл может использовать стандартный.

Мысль об использовании конфигурации для ключей api не является новой или неслыханной. Службы Bit.ly делают это. И все приложения с открытым исходным кодом, которые я вижу, обеспечивают использование с Bit.ly, запрашивая ваше имя пользователя и ключ api, прежде чем вы сможете его использовать.

Это ничем не отличается?