Могу ли я действительно не поставлять открытый исходный код с идентификатором клиента?

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

(https://developers.google.com/terms/, мой акцент)

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

Не так уж сложно извлечь идентификатор клиента и «секрет» клиента из не-открытого исходного кода, так почему же такое различие?

Идентификаторы и секреты клиента «установить приложения» на самом деле не являются секретами, и документация Google, похоже, согласна:

Результатом процесса является идентификатор клиента и, в некоторых случаях, секрет клиента, который вы встраиваете в исходный код своего приложения. (В этом контексте секрет клиента, очевидно, не рассматривается как секрет.)

(https://developers.google.com/accounts/docs/OAuth2, снова мой акцент)


person Thomas    schedule 20.12.2014    source источник
comment
Я голосую за то, чтобы закрыть этот вопрос как не относящийся к теме, потому что он касается лицензирования или юридических вопросов, а не программирования или разработки программного обеспечения. см. здесь и здесь для получения подробной информации и в справочном центре чтобы узнать больше.   -  person JasonMArcher    schedule 18.06.2015


Ответы (2)


5 ноября 2014 г. Google внесла некоторые изменения в Условия использования API. .

Как и у вас, у меня была проблема со следующей строкой.

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

У меня есть несколько проектов с открытым исходным кодом на GitHub, они в основном представляют собой учебные пособия по использованию API Google, некоторые API все еще находятся в стадии бета-тестирования, и для получения доступа к бета-версии требуется время. Я встроил свой идентификатор клиента в свои проекты, чтобы мои пользователи могли тестировать приложения.

Теперь у меня есть несколько контактов в Google, поэтому я надеялся, что смогу получить здесь какое-то разрешение. Мне удалось разыскать автора вышеупомянутого оскорбительного изменения сервиса Дэна Цирули и отправить ему электронное письмо.

Мое электронное письмо было довольно логичным, вы можете прочитать его здесь: Изменения службы

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

Однако вы позволяете им «выдавать себя за вас» в глазах Google. Если наши системы злоупотреблений обнаружат злоупотребление (например, если кто-то попытается атаковать один из наших сервисов с помощью вашего ключа), вы рискуете, что из-за этого ваш аккаунт будет удален (и обратите внимание — они не просто отключат доступ к ключ, они закроют вашу консольную учетную запись). Кроме того, вам был предоставлен доступ из белого списка к API, которые недоступны для широкой публики (и, по всей вероятности, требуют согласия с отдельными Условиями обслуживания) и предоставляют доступ всем, кто этого хочет. Нет сомнений, что это нарушение этих условий. Извините, что у вас нет ответа, который вы ищете, но ключи — это единственный способ узнать, кто звонит в наши службы.

Это только часть его электронного письма ко мне. Полностью пост можно прочитать по ссылке выше. Итак, если вы даете им исходный код, и они могут видеть идентификатор клиента. Вашим пользователям придется создать собственный проект в консоли Google Cloud. Обойти это невозможно.

Надеюсь, это помогло.

person DaImTo    schedule 23.01.2015
comment
Ну, если под помощью ты имеешь в виду забить гвоздь в гроб моей надежды на хорошее решение, то да. Эх, так и должно быть. Спасибо за очень хороший ответ. - person Thomas; 25.01.2015
comment
Извини. Если это поможет, вы не единственный, кто был укушен этим. У меня был этот разговор с несколькими другими. Любые php-плагины для WordPress также подходят для этого. - person DaImTo; 25.01.2015
comment
Собственные инструкции Google по настройке входа через Google (developers.google.com /identity/sign-in/web/sign-in) предписывает поместить идентификатор клиента в ‹метатег›, что означает, что он общедоступен. Очевидно, что секрет клиента не следует размещать в коде, но идентификатор клиента должен быть общедоступным, не так ли? - person reynoldsnlp; 13.05.2015
comment
(извините, если это старо) Я не вижу ответа на комментарий бибопа. Я не понимаю, почему идентификатор клиента должен быть секретным, поскольку я могу легко получить любой идентификатор клиента, который мне нужен, просто зайдя на указанный сайт, щелкнув вход в Google. Он находится прямо в URL-адресе. Это невозможно скрыть!? Может быть, мне следует начать новый вопрос SO конкретно об этом. - person Bernard; 08.01.2016
comment
@ Бернард, ты задал вопрос? - person Yasushi Shoji; 31.12.2016

Есть лучший вариант, и он называется динамической регистрацией клиента OAuth 2.0. Однако над этим все еще ведется работа: https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-21, и поставщикам может потребоваться некоторое время, чтобы принять и внедрить его.

Редактировать:

Категорически невозможно отправлять секреты аутентификации с помощью приложения с открытым исходным кодом. [Честно говоря, действительно не имеет смысла поставлять их с каким-либо приложением; это просто более очевидно с приложениями с открытым исходным кодом.]

person Hans Z.    schedule 21.01.2015
comment
Вопрос говорит о Google Oauth. Что не поддерживает то, о чем вы говорите. Как это отвечает на вопрос? - person DaImTo; 24.01.2015
comment
Тот факт, что нет никакой реальной разницы между размещением учетных данных в открытом и закрытом исходном коде, является причиной того, что я не могу понять эту политику. В любом случае вы можете извлечь и использовать его повторно. - person Thomas; 25.01.2015
comment
Немного сложнее получить их из cq с закрытым исходным кодом. двоичные файлы, и, по-видимому, именно здесь Google проводит черту; методы запутывания также могут немного помочь (хотя в политике об этом не говорится); кроме того, нет никакой хорошей альтернативы нативным мобильным приложениям, пока не появится динамическая регистрация клиентов (поэтому я думаю, что имеет смысл упомянуть об этом...) - person Hans Z.; 25.01.2015