Ответ:
Чтобы вставить методы в Календарь пользователя, вам нужно, чтобы пользователь дал вашему приложению разрешение на выполнение действий от его имени. Это делается с помощью проекта Google Cloud Platform (GCP) с аутентификацией OAuth2.
Дополнительная информация:
Каждое приложение, которое запускается и выполняет действия от имени пользователя учетной записи Google, имеет четко определить объем его возможностей, чтобы он не мог начать делать то, на что пользователь не дал ему разрешения.
Например, : если вы даете приложению разрешение на создание событий календаря, вы не хотите, чтобы он мог делать другие вещи, например читать ваши электронные письма или загружать содержимое вашего Диска.
Чтобы указать, что ваше приложение может делать , он должен быть зарегистрирован в Google. Как вы уже поняли в своем вопросе и комментариях, идентификатор клиента и секрет клиента, необходимые приложению, подключающемуся к G Suite API, - это не просто имя пользователя и пароль учетной записи Google, а назначенная пара ID-секретный идентификатор, которая является предоставленный Google для идентификации вашего приложения.
OAuth2:
OAuth2 - это особая структура авторизации c. Структура определена в RF C 6749 и устанавливает процесс, в котором пользователь может авторизовать приложение для доступа к своей учетной записи. Предел авторизации определяется областью действия приложения при авторизации и не может быть изменен без явной повторной авторизации пользователем.
Прежде чем продолжить, стоит определить здесь несколько важных терминов:
Пользователь:
Пользователь - это человек; лицо, которое имеет учетную запись и дает разрешение приложению действовать от его имени.
Клиент или приложение:
Клиент или Приложение - это программа, которая предназначена для выполнения действий через HTTP путем подключения к API службы. Приложения могут быть мобильными, веб-приложениями или клиентами для настольных ПК.
Сервер авторизации:
Сервер авторизации - это сервер, отдельный от серверы, на которых хранятся пользовательские ресурсы. Он проверяет личность пользователя и предоставляет грант, который можно использовать для получения токена доступа к серверу ресурсов.
Сервер ресурсов:
Это сервер, на котором хранятся пользовательские данные. Это может быть что угодно, от пользовательской информации до файлов или электронных писем.
Процесс авторизации уже хорошо документирован, но для этого сценария мы можем абстрагировать его до следующих шагов:
- Приложение желает выполнить действие на сервере ресурсов от имени пользователя.
- Приложение отправляет пользователю запрос на авторизацию. Обычно это отображается как страница входа в систему для учетной записи, к которой приложение обращается.
- Пользователь входит в свою учетную запись и отображается экран согласия OAuth - он содержит такую информацию, как имя приложения и список задач, для которых запрашивается авторизация. Часто это общие c, в которых написано что-то вроде
See and download all your Google Drive files или View and edit events on all your calendars. Это позволяет пользователю знать какие они авторизуют до подтверждения. - Приложению предоставляется разрешение на авторизацию.
- Приложение предоставляет полученное разрешение на авторизацию вместе с назначенные ему учетные данные клиента для сервера авторизации.
- После проверки правильности и предоставления, и учетных данных клиента сервер авторизации возвращает маркер доступа, который можно использовать для доступа к запрошенным и утвержденным ресурсам. Примечание: обычно все это обрабатывается вашей клиентской библиотекой для любого языка, который вы используете .
- Приложение теперь может делать запрос к серверу ресурсов, предоставляя токен доступа, полученный из потока авторизации . Именно в этот момент можно получить доступ к разрешенным ресурсам.
Проекты Google Cloud Platform:
Проект GCP, который Google считает вашим приложением. Регистрация для вашего приложения необходима, чтобы иметь возможность получить идентификатор клиента и секрет клиента, которые потребуются вашему приложению для получения токена доступа в потоке авторизации. В консоли GCP вы можете настроить все необходимые службы, которые нужны вашему приложению. Каждый API, который вы используете sh, должен быть включен для вашего приложения, так как существует множество служб Google с API , и они отключены по умолчанию.
После того, как проект GCP был запущен Созданный, вы можете использовать библиотеку API (из пункта меню ≡ > APIs & Services > Library слева), чтобы найти и включить API. Обратите внимание, что для вашего варианта использования вам потребуется включить API Календаря Google, а не API CalDAV.
Вам также необходимо будет настроить экран согласия перед получением учетных данных для вашего приложения. Экран согласия OAuth - это то, что вашим пользователям будет представлено на первом этапе потока OAuth:
When setting up your OAuth consent screen, you will need to provide the following information:
- Application type (public or internal to your domain)
- Application name
- The scopes that your application needs (explained in the next section)
After the consent screen has been set up, you can download the client credentials for your application. With these, your application has permission to run as a client, but each user that has their resources accessed will still have to give their explicit permission to allow the application to do so.
Scopes:
Within a single API there can be many scopes of access - having read-only access to calendar events is vastly different to having complete read-write access to all calendars that a user owns. This is where scopes come into play.
A scope is defined as its namesake; that is to say, a scope defines the scope of access an application has to a service. Even though an entire API has been enabled for a project doesn't mean that you need to use all features of the API. For this reason, scopes need to be defined.
Scopes are defined in the application itself before making the initial request for the user grant. In C#, for example (taken from the . NET Краткое руководство по API календаря ):
// scopes are defined as an array of strings:
static string[] Scopes = { CalendarService.Scope.CalendarReadonly };
...
UserCredential credential;
credential = GoogleWebAuthorizationBroker.AuthorizeAsync(
GoogleClientSecrets.Load(stream).Secrets,
Scopes,
"user",
CancellationToken.None,
new FileDataStore(credPath, true)).Result;
Маркер доступа, который сохраняется, основан на областях, которые были определены в вызове. Если вызывается метод, для которого требуется другая область видимости, чем та, к которой токен предоставляет доступ, вызов завершится с ошибкой 403: Unauthorized. Требуемая область должна быть добавлена в приложение, старый токен доступа удален, и пользователю необходимо будет предоставить разрешение для новых областей.
Учетные записи служб:
А также обычных пользователей есть еще один особый тип учетной записи Google, называемый служебной учетной записью. Из документации:
Учетная запись службы - это особый тип учетной записи, используемый приложением или экземпляром виртуальной машины (ВМ), а не человеком. Приложения используют учетные записи служб для выполнения авторизованных вызовов API.
Обычно каждый пользователь, для которого вы sh выполняете задачи или получаете доступ к ресурсам, должен дать явное разрешение вашему приложению на это. Однако для доменов G Suite вы можете использовать сервисный аккаунт с делегированием всего домена для выполнения задач от имени пользователей без необходимости.
Сервисные аккаунты используют особый вид сервиса - учетные данные, которые можно создать в GCP и использовать в вашем приложении. Вместо создания объекта UserCredential требуется ServiceAccountCredential, который не требует участия конечного пользователя .
При запуске учетной записи службы от имени пользователя с доменом - широкое делегирование, имя пользователя должно быть указано в делегированных учетных данных, чтобы приложение знало, от имени какого пользователя в домене запускаться. Если пользователь не указан, учетная запись службы запустит код как сама; что полезно в некоторых случаях, но часто не возвращает ошибку, поэтому может быть неясно, для кого была запущена операция.
Примечание: Хотя учетные записи служб могут быть созданы кем угодно делегирование полномочий на уровне домена может быть выполнено только для домена G Suite, но не для адресов @gmail.com. Все пользователи учетной записи Gmail должны дать явное разрешение для запуска приложения от своего имени, как указано в потоке OAuth.
Надеюсь, это будет полезно для вас!
Ссылки:
Связанные вопросы: