Рекомендуется ли предоставлять учетные данные API Google Drive для использования в сценарии? - PullRequest
0 голосов
/ 23 мая 2018

В двух словах: Должен ли я предоставить учетные данные oauth2 в нашем исходном коде с целью полного доступа для записи на диск Google из выделенного одноцелевого аккаунта Google?

Итак, я написал скрипт на Python, который сохраняет некоторые данные либо в уже существующий файл google-листов, либо создает новый файл google-листов в заданную папку на диске Google (оба из которых являются общедоступными).редактируемый для разделения целей между командами).

Для этого я следовал инструкциям и учебникам, описанным google и другими источниками, после чего я получил oauth2-учетные данные, необходимые для аутентификации моего скрипта с помощью Google Drive и API Google Maps.

Эти учетные данные получены из одноцелевой учетной записи Google, которую я создал для этого сценария.

Теперь я хотел бы поделиться этим сценарием с другими членами команды, но не уверен в том, какприступить к проверке полномочий;либо:

A.)

Я бы включил предложенный рабочий процесс Google, который позволил бы пользователю скрипта аутентифицировать себя, то есть пользователь запускаетсязатем скрипт направляется в веб-журнал google-authentication, аутентифицирует скрипт, а затем скрипт сохраняет и использует эти учетные данные пользователя для записи данных в общедоступный файл google-листов (не обязательно частный, принадлежащий пользователю).).

У этого есть недостатки:

  • пользователь будет доверять моему сценарию учетные данные, которые могут позволить ему читать / записывать все данные диска пользователяучетная запись.Хотя я, конечно, не имею в виду никакого вреда, все же, кажется, слишком много просить и нести ответственность за
  • , это нарушает предполагаемый прямой рабочий процесс моего сценария.
  • не требуется ввсе технически, потому что скрипт должен записывать только в публичные листы-файлы / папки на дисках;так зачем ему нужен доступ на запись ко всем файлам диска пользователя?.

B.)

жестко закодировать учетные данные наших одно-целевая учетная запись в сценарии;что имеет единственный недостаток: когда исходный код скрипта будет предоставлен, любой может получить эти учетные данные.Но эти учетные данные позволят злоумышленнику только записать / прочитать данные на диск Google учетной записи, но не получат контроль над всей учетной записью из-за ограничений области действия учетных данных oauth2 (я использовал "https://www.googleapis.com/auth/drive" scope ). Кроме того, как было сказано ранее, мы будем использовать скрипт только для чтения / записи данных в публичные листы-файлы, которые принадлежат реальным учетным записям Google, поэтому никогда не будем использовать дискодноразовая учетная запись и, следовательно, никакой злоумышленник не может уничтожить наши данные.

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

Что бы вы предложили?

1 Ответ

0 голосов
/ 12 июня 2018

Мы выбрали вариант A: пользователи должны сами создавать файлы client_secret.json и credentials.json.К сожалению, он не самый прямой, но самый безопасный.Совместное использование учетных данных в общедоступном репо - это просто большой запрет, независимо от деталей.

Также ради полноты: еще одна альтернатива - запуск приложения на сервере, где мы можем сохранить client_secret., так что тогда пользователю будет просто представлено всплывающее окно браузера, где он / она авторизует наш сервис.

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

Это наша мотивация для принятия решения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...