Блог

Мы пытаемся пройти аутентификацию в BigQuery в сценарии R, запланированном для запуска на сервере Linux. У нас есть:

 bigrquery::bq_auth(path = '~/path-to/credentials/our-creds.json')
 

и когда я запускаю это локально в R, я получаю следующее приглашение

 The bigrquery package is requesting access to your Google account.
Select a pre-authorised account or enter '0' to obtain a new token.
Press Esc/Ctrl   C to cancel.

1: myemail@gmail.com

Selection: 
 

Когда мы запускаем это на нашем сервере Linux через Rscript our_script.R , мы получаем следующую ошибку:

 Error: Can't get Google credentials.
Are you running bigrquery in a non-interactive session? Consider:
  * Call `bq_auth()` directly with all necessary specifics.
Execution halted
 

Когда мы запускаем это на нашем сервере Linux через R , чтобы открыть R, а затем вручную запускаем строку кода, мы получаем:

 > bigrquery::bq_auth(path = '~/path-to/credentials/our-creds.json')
Waiting for authentication in browser...
Press Esc/Ctrl   C to abort
 

и поскольку у нас нет браузера для аутентификации (мы подключены по SSH к нашему серверу Linux, который работает на GCP), терминал зависает здесь…

Как мы можем успешно пройти аутентификацию на сервере, чтобы Rscript out_script.R успешно работать?

Редактировать: Информация на нашем сервере:

дайте мне знать, если я могу поделиться дополнительной информацией, чтобы помочь в этом. Также мы попытались добавить myemail@gmail.com email параметр bigrquery, но это не решило проблему. Я вижу, что есть token параметр, и, возможно, мы можем где-нибудь вручную добавить токен? Все это очень расстраивает, потому что я думал, что использование ключа учетной записи службы должно было решить эту проблему, и все же мы указываем на действительный ключ учетной записи службы с разрешениями bigquery, и все же не можем пройти аутентификацию на сервере.

Тот же вопрос был задан на форуме сообщества RStudio. Публикую обсуждение здесь для потомков.

Несколько идей по устранению неполадок:

… R скрипт, запланированный для запуска на сервере Linux….

Всякий раз, когда я слышу «запланировано», я думаю «cron», а когда я слышу «cron», я думаю «проблемы с путями». Поэтому в контексте сервера / расписания я рекомендую проводить очень педантичные проверки, чтобы вы действительно понимали, что такое рабочий каталог, кто такой пользователь и соответствует ли путь вашим намерениям.

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

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

gargle.r-lib.org — Устранение неполадок при полоскании горла.

И в случае, если вы еще не нашли его (и в интересах других читателей), вот общий обзор того, как настроить неинтерактивную аутентификацию:

gargle.r-lib.org — Неинтерактивная аутентификация — полоскание горла

Как признал @Canovice в той же теме форума, проблема возникла из-за неправильного ключа учетной записи службы, используемого в bq_auth() функции.