Комментарии 7
Вы уверены что это то что должно работать у клиентов? Через сервисный аккаунт? Я делал иначе, создается приложение в гугл консоли, после чего для авторизации пользователю дается ссылка открыв которую в браузере он должен получить ключ(по-моему это называется рефреш токен). Этот токен он отдает вашему приложению и вы его должны сохранить. Но по нему нельзя работать с АПИ, его нужно поменять на другой токен и вот с ним обращаться к АПИ. Могу более подробно кодом показать как это делается.
Что бы конкретный пользователь мог работать с конкретной таблицей должны совпасть две вещи 1) идентификация пользователя (что бы проверить что у него есть доступ к таблице), 2) идентификация приложения (гугл заставляет ваш код представляться каждый раз когда вы хотите вызвать его АПИ)
Я не совсем понимаю первые два вопроса. Клиентам при использовании такого подхода нужно лишь указать имя JSON-файла, который выдаётся для сервисного аккаунта Google. Программа преобразует этот файл в JWT-токен, указывает сервис, к которому нужен доступ, затем получает OAuth-токен от сервера Google, добавляет его в заголовок запроса и с его помощью получает доступ к таблице.
У меня всё работает отлично: я синхронизирую базу данных с Google-таблицей и наоборот. Не совсем понимаю, зачем использовать Google консоль, если всё можно реализовать в C++. Буду рад, если вы покажете ваш подход — было бы очень интересно увидеть, как это можно сделать по-другому.
Это не совсем правильный путь. Клиентам не нужно создавать сервисный аккаунт. С точки зрения пользователя авторизация выглядит вот так.
1) пользователю ваша программа дает URL - это специальная ссылка которая формируется по определенным правилам. Пользователь должен ее скопировать и вставить в браузер. После чего ему будет показано окно где будет видно какое приложение, какой компании запрашивает доступ к его аккаунту. Как альтернатива это окно можно открывать из вашей программе, а потом доставать ключ автоматически.
2) После авторизации пользователя ему выдает ключ, этот ключ он должен отдать вашей программе.
3) Ваша программа используя ключ от пользователя (не сервисный аккаунт). Может получать доступ через Гугл АПИ к данным в аккаунте пользователя.
При таком подходе пользователь может в любой момент смотреть каким приложениям он дал доступ и отозвать его, а так же при авторизации выбирать аккаунт.
При подходе с сервисным аккаунтом пользователь тоже может в любой момент отозвать ключ ,который даёт программе, доступ к таблице вообще убирается 2мя кликами. В случае с сервисным аккаунтом пользователю вообще не надо никаких разрешений на свой аккаунт давать.
Не понимаю чем подход с сервисным аккаунтом неправильный.
Тем что это противоречит документации Google. Пользователи должны работать через авторизацию для пользователей, а сервисный аккаунт это условно аналог рута в ОС, почему пользователи в ОС работают в пользовательском пространстве? Ведь это их компьютер могут и от рута все запускать и вообще заходить в систему из под рута, верно? (ну могли бы в старых версия линукса, сейчас вроде нельзя зайти из под рута, отключили), по этой же причине отключили su, теперь только sudo. Потому что это нарушение правил безопасности, дает слишком много полномочий и плохо поддается контролю и вообще система не рассчитана на работу пользователей из под сервисного аккаунта, само название как бы намекает о его предназначение.
Пользователь не должен заходить в консоль, ему там делать нечего. И уж тем более он не должен брать оттуда ключи и отдавать их куда-то.
Единственный пользователь, который в этом случае работает с сервисным аккаунтом, — это владелец телеграм-бота. У пользователей ТГ-бота есть только интерфейс для взаимодействия с БД, а из БД через сервисный аккаунт данные отправляются менеджерам в Google Таблицу.
Сервисный аккаунт для этого и нужен, чтобы дать его ключ приложению и оно автоматически выполняло необходимые действия, в нашем случае синхронизация Google таблицы с БД.
Google sheets with C++