Соединитель сообщества Google Data Studio. Как передать учетные данные сторонней конечной точке нескольким пользователям? - PullRequest
Новая
       9

Соединитель сообщества Google Data Studio. Как передать учетные данные сторонней конечной точке нескольким пользователям?

0 голосов
/ 08 ноября 2018

Я разрабатываю пользовательский коннектор сообщества для Google Data Studio с потенциальной целью опубликовать его для других пользователей.

По сути, он подключается к внешней конечной точке REST, запрашивает данные в соответствии с тем, что пользователь настроил в графическом интерфейсе источника данных, получает данные и преобразует их, чтобы Google Data Studio могла их обрабатывать.
Разъем использует AuthType USER_PASS. Поэтому, когда пользователь Google создает источник данных из этого соединителя, ему будет предложено ввести комбинацию пользователя и пароля для аутентификации на этой внешней конечной точке REST. Это выглядит примерно так:

imageUSER_PASS">

Однако рассмотрим такой сценарий:

Google User A создает источник данных из соединителя.

  1. Он настраивает этот источник данных для аутентификации во внешней службе с именем пользователя пользователь и паролем пароль .
  2. Он создает отчет, используя этот источник данных.
  3. А потом еще один отчет.
  4. А потом, может быть, другой.
  5. Он делится одним из этих отчетов с кем-то еще

Теперь пользователь Google B получает электронное письмо, в котором сообщается, что есть отчет, который он может просмотреть. Он нажимает на ссылку. Сразу же getData() вызывается. Но может и не быть, я не совсем понял, как работает кеширование. Возможно, ему разрешено редактировать отчет. Так он и делает. После значительных изменений, внесенных в этот отчет B , getData() вызывается в любом случае. Но источник данных не будет знать, какие учетные данные он должен использовать для аутентификации на внешней конечной точке REST.

Я поиграл с различными CacheService s и PropertiesService s для хранения этой информации. Я узнал, что кэш и свойства в основном совпадают, за исключением того, что срок действия кэша ограничен до истечения срока его действия.

  • DocumentProperties / DocumentCache всегда имеет значение null, потому что, насколько я понимаю, он не предназначен для использования с соединителем.
  • ScriptProperties / ScriptCache совместно используется всеми экземплярами соединителя, как и во всех источниках данных, использующих этот соединитель. Это слишком ограничено, так как, возможно, пользователь желает использовать этот соединитель для нескольких учетных записей для этого REST API этой внешней службы.
  • UserProperties / UserCache слишком ограничен, так как он отличается для Google User A и Google User B .

Так что вопрос: Где мне хранить user и password для аутентификации этого экземпляра соединителя с внешней службой REST?

1 Ответ

0 голосов
/ 13 ноября 2018

Меня вдохновило Session.getEffectiveUser () , которое отличается в зависимости от пользователя, под чьим полномочием запускается скрипт.

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

В основном, если вы выбираете «Доступ к учетным данным владельца», который является значением по умолчанию, UserProperties / UserCache создателя передаются всем другим пользователям. Принимая во внимание, что если вы выбираете «Доступ к учетным данным зрителя», то используются UserProperties / UserCache текущего зрителя.

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

...