2013-04-08 5 views
4

Условия использования для libspotify указывают, что ключ должен храниться безопасным образом. Единственная рекомендация по хранению ключа, который я нашел, заключается в компиляции вашего приложения и распространении двоичного файла. Мне нелегко видеть это как что-то еще, кроме безопасности от неизвестности, поскольку ключ легко извлекается с помощью отладчика.Предотвращение неправильного использования ключа libspotify

Действительно ли это подход Spotify предлагает? Что, если я только компилирую файл, содержащий ключ, и распространяю остальную часть моего приложения как открытый источник?

Я предполагаю, что суть моего вопроса такова: как я могу избежать нарушения ToS, не требуя от каждого пользователя получить свой собственный ключ?

+0

Этот вопрос не соответствует теме, поскольку речь идет о Условиях обслуживания. Только вопросы о spotify api по теме. – quetzalcoatl

ответ

6

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

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

Чтобы заставить себя испытать ужасную аналогию с автомобилем, представьте, что ключ API - это ценный предмет, и ваше приложение - это автомобиль. Если вы оставите элемент на сиденье автомобиля (т. Е. Имея свой ключ API в виде обычного текста), вы практически приглашаете кого-то вломиться и украсть его (т. Е. Использовать свой ключ в своем собственном приложении). Если вы положите его в перчаточный ящик (скомпилируйте его в свой бинарный файл), если кто-то перерыл ваш автомобиль (разобрал ваше приложение), потому что он знает, что предмет находится в перчаточном ящике, это в значительной степени игра в любом случае.

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

Я предполагаю, что суть моего вопроса такова: как я могу избежать нарушения ToS, не требуя от каждого пользователя получить свой собственный ключ?

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

+0

Я вижу, спасибо за разъяснение. Однако могу ли я попросить вас рассказать следующее о вашем последнем заявлении: я понимаю, что мне не разрешено распространять ключ как открытый, но как его перераспределять (ключ) в качестве объектного кода, сохраняя при этом остальная часть источника открыта? Конечно, я понимаю: могу ли я добавить источник моего приложения (например) в публичный репозиторий GitHub вместе с скомпилированной версией моего ключа? Я понимаю, что в конце концов, я отвечаю за свой ключ. Мне просто интересно, что Spotify стоит на этом. –

+0

Мне нужно будет избавиться от этого вопроса, так как он находится прямо на краю - да, он скомпилирован, но appkey.o будет довольно легкой целью. – iKenndac

+0

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