#google-api #google-calendar-api #service-accounts #google-api-java-client
Вопрос:
Я могу создать событие в Календаре Google, используя учетную запись службы и API Календаря Google, где учетная запись проекта и службы создается в учетной записи администратора Google Workspace, и в той же учетной записи я включил свойство делегирования домена. Я не создавал отдельный календарь и не предоставлял доступ к учетной записи службы. Если я использую свою учетную запись workspace-Google в createDelegated(), это событие создается в ‘abc@myworkspace.com свойство «календарь» и «создано» также одинаковы для каждого добавленного мной участника.
GoogleCredentials googleCredentials = GoogleCredentials
.fromStream(new FileInputStream(CREDENTIALS_FILE_PATH)).createScoped(SCOPES)
.createDelegated("abc@myworkspace.com");
Итак, мой вопрос в том, что, если мне нужно создать событие для учетной записи Google, не относящейся к рабочему пространству (скажем def@gmail.com )
Могу ли я передать ‘def@gmail.com ‘ в createDelegated()? Если я это сделаю, я получаю,
Error getting access token for service account: 400 Bad Request
Итак, как создать событие для учетной записи Google, не относящейся к рабочему пространству?
Примечание: тип приложения по-прежнему «Внутренний» на экране согласия OAuth.
Может кто-нибудь объяснить, чего мне здесь не хватает?
Ответ №1:
Учетная запись службы с делегированием домена может использоваться только для доменов
Учетная запись Google Workspace — это домен, личная учетная запись пользователя не является доменом.
Следовательно, вы не можете выполнить запрос от имени пользователя учетной записи пользователя через учетную запись службы.
Вместо этого вам нужно будет создать событие напрямую, def@gmail.com аналогично образцу документации.
Комментарии:
1. Не могли бы вы рассказать мне, как был создан объект service ? Я хочу сказать, каким образом оно создается? разве оно не создано с помощью ключа учетной записи службы?
2. @TheSagya фактический механизм, с помощью которого достигается авторизация учетной записи службы, немного сложнее, чем просто ключ учетной записи службы Попробуйте прочитать это С помощью OAuth 2.0 для сервер-серверных приложений Обратите пристальное внимание на то, как создается JWT.
3. Нет, при использовании этого рабочего процесса объект service создается, как описано здесь . Для этого потока вам необходимо загрузить и использовать user cedentials json вместо ключа учетной записи службы. Пользователю необходимо вручную авторизовать приложение, как описано здесь .
Ответ №2:
Нет, вы можете удалить только учетную запись в своем домене
createDelegated("abc@myworkspace.com");
Вы не можете перейти к стандартной учетной записи Google, поскольку у вас не будет возможности настроить разрешения
выполнить делегирование полномочий по всему домену -google-workspace
Выполните делегирование полномочий в масштабах домена Google Workspace
Примечание: только пользователи, имеющие доступ к API Admin API, могут получить доступ к API Admin SDK Directory, поэтому ваша учетная запись службы должна выдавать себя за одного из этих пользователей, чтобы получить доступ к API Admin SDK Directory. Кроме того, пользователь должен войти в систему хотя бы один раз и принять Условия обслуживания Google Workspace.
Владелец против участника.
Учетная запись службы делегирована надлежащим образом. Будет иметь разрешение на создание события от имени пользователя в домене, которому им было делегировано разрешение.
Пример: я делегировал разрешение на мою учетную запись службы пользователю User1@myDomain.com . Для всех интенсивных целей учетная запись службы теперь имеет все разрешения User1. Таким образом, учетная запись службы может создать новое событие от имени user1 и пригласить любого на мероприятие, которое они выберут.
Поскольку нет способа настроить делигацию на user2@gmail.com учетная запись службы не может действовать как этот пользователь, поскольку это обычный пользователь gmail.
Единственный способ для приложения создать событие от имени user2@gmail.com было бы использовать Oauth2 и запросить согласие User2@gmail.com чтобы получить доступ к их личным данным. Тогда приложение сможет создать новое событие от имени User2@gmail.com .
Помните, что это создает событие. Ничто не мешает учетной записи службы, делегированной как user1@mydomain.com от приглашения user2@gmail.com к событию. user2@gmail.com затем они получат уведомление о том, что их пригласили на мероприятие, на котором они могут решить, хотят ли они присутствовать или нет, если они примут его, оно появится в их аккаунте Google Calendar. Обратите внимание, как user2@gmail.com пришлось вручную принять это. User1@mydomain.com им не нужно было вручную соглашаться с тем, что событие было создано в их календаре Google, поскольку учетная запись службы действовала от их имени.
Комментарии:
1. Не могли бы вы направить мне ссылку, по которой я могу создать событие для стандартной учетной записи Google с помощью API? что должно быть связью между серверами, и в стандартной учетной записи Google не должно быть экрана согласия?
2. Вы не можете. Учетные записи служб работают только с учетными записями Workspace. Если вы хотите создать событие в моей учетной записи календаря Google, вам нужно мое разрешение, чтобы получить это разрешение, вам нужно пройти авторизацию Oauth2 и запросить разрешение. Пример java Oauth2 календаря Google
3. Хорошо, теперь я создал учетную запись службы и использовал ее ключ JSON для авторизации, и с его помощью я могу создать событие в своем календаре (это моя учетная запись workspace).). В этом событии я добавил свою стандартную учетную запись Google (учетную запись, не относящуюся к workspace) в качестве участника, и я могу видеть конкретное событие в календаре моей стандартной учетной записи Google, где created by property — это моя учетная запись workspace. И не было запрошено никакого разрешения для моей стандартной учетной записи Google.
4. Это потому, что вы добавили обычного пользователя в качестве участника. Вероятно, этот пользователь получил электронное письмо и должен был принять это событие. Существует разница между участником и владельцем события. Вы не можете напрямую создать событие в моей учетной записи календаря Google, владельцем которой я являюсь, без моего разрешения. Вы можете пригласить меня на мероприятие, владельцем которого вы являетесь, и если я приму его, я буду добавлен.
5. Да, прежде всего, я использовал стандартную учетную запись Google (A) в качестве участника, и процесса принятия не было, тем не менее событие было создано в Календаре в качестве участника события. Это нормально, на самом деле, я думаю, вы поняли мою проблему, мне нужно создать событие, которое может (ИЛИ должно) быть создано только в календаре моей учетной записи workspace, но оно должно быть создано таким образом, чтобы другие участники (кроме стандартной учетной записи (A)) должны создать событиев их календаре только как участник, но он покажет, что владелец является стандартной учетной записью Google (A), возможно ли это?