Аутентификация на внешних сервисах посредством OAuth

03.04.19

Администрирование - Информационная безопасность

Пример подключения к сервисам Google из 1С с помощью протокола OAuth и получения данных с внешнего сервиса.

Скачать файлы

Наименование Файл Версия Размер
Аутентификация на внешних сервисах посредством OAuth:
.epf 13,71Kb
74
.epf 1.0 13,71Kb 74 Скачать

 В данной  статье на примере подключения к сервисам Google я продемонстрирую реализацию подключения к сервисам Google при помощи аутентификации по протоколу OAuth 2.0 на языке программирования 1С.  В статье будет показана реализация подключения к сервису календарей Google с помощью авторизации по протоколу OAuth 2.0. Получение списка календарей и загрузка событий календаря на форму.

Сперва следует немного рассказать о популярном ныне протоколе аутентификации OAuth который сейчас используется повсеместно.

OAuth - открытый протокол (схема) авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль(ru.wikipedia.org/wiki/OAuth). Суть такого вида аутентификации является отсутствие необходимости передавать логин и пароль к персональным данным или регистрироваться на сервисе проходя нудную процедуру регистрации затем хранить пароли от разных аккаунтов, да и сервисам полегче не нужно создавать системы хранения учётных данных и ещё и отвечать за их возможную утечку. Пользователь может быть уверен что приложению будет доступен только тот набор данных которые он разрешил.  Также можно гарантировать что приложение будет продолжать работать пока пользователь не запретит ему доступ к своим данным, при этом пользователь может менять пароль и это никак не скажется на работе приложения. После получения доступа приложение может работать не требуя от пользователя подтверждения своих привилегий доступа (хотя у сервисов предоставляющих доступ есть свои ньюансы на этот счёт).

Итак как работает этот протокол аутентификации. В стандарте описана несколько схем работы протокола на все случаи жизни от авторизации на Web серверах до аутентификации на Smart-телевизорах. Жаждущие подробносей могут углубиться в чтение на https://www.digitalocean.com/community/tutorials/oauth-2-ru. В статье я не буду подробно останавливаться на деталях и особенностях этого протокола. В статье будет описан только наиболее часто используемый способ авторизации - получение токена доступа через код авторизации.

Итак аутентификация состоит из трёх последовательных этапов и одного предварительного связанного с регистрацией 1С обработки в качестве приложения на сервисах Google. Для приложения мы активируем API для тех типов данных, доступ к которым нам понадобится для приложения, ещё в приложении мы создадим OAuth идентификатор нашего приложения.

Начнем с предварительного этапа, регистрации приложения.

Нам потребуетя войти в консоль Google Api с действующей учетной записи Google по ссылке https://console.developers.google.com/apis/dashboard.

Создадим проект.

 

 

Следующим шагом нам нужно определиться какие API Google мы будем использовать, их надо активировать. Сделать это можно перейдя кликнув на ссылке перейти к обзору API ниже на рисунке. Для наших целей достаточно Calendar API.

 

 

 

Осталось создать идентификатор учётных данных OAuth. На картинке жмем Учётные данные,
Теперь создаём идентификатор OAuth

 

 


 

 

Далее открывается вот такое модальное окно, в котором Google предлагает нам настроить окно подтверждения пользователем доступа к их данным. Это то самое окно в котором вы даёте согласие на доступ к своим учётным данным. Настроим, жмём на Set up Consent Screen.

Здесь нас интересуют области действия для API Google. Это те разрешения на доступ к персональным данным которые мы будем просить у пользователя. Для примера достаточно прав чтения данных календаря (read only).  В нашем примере нам нужны такие права
 

 

 

 

 

Нажимаем сохранить. И переходим в учетные данные для создания идентификатора OAuth.

 

 

Итак, с консолью Google мы закончили. Для удобства можно скачать файл JSON. В нём содержатся все требуемые данные которые потребуются нам в дальнейшем.
Пора заняться подключением из 1С.
И это только предварительный этап😊.

 

Этапы авторизации будут располагаться совместно с их реализацией в обработки. Сама обработка будет состоять из двух форм, первая основная на которой будут отображаться получаемые данные и вспомогательная, служащая в качестве встроенного web-браузера для отображения веб страницы пользователю, в которой он сможет разрешить для нашего приложения доступ к своим данным.доступ к пользовательским данным. Поле в котором будет отображаться страница имеет вид полеHTMLДокумент

Версия платформы на которой тестировалась обработка 8.3.14, в которой, наконец-то, был заменен веб-движок с престарелой версией Internet Explorer на современный WebKit. Что само по себе открывает огромные возможности по взаимодействию с интернетом из 1С.

 

 

Первый этап.  1.    Обращение к авторизационному серверу за разрешением пользовательских данных. Авторизационный сервер это сервис который хранит пользовательские данные и предоставляет доступ к пользовательским данным. На этом этапе формируется GET запрос со следующими параметрами

client_id - идентификатор нашего приложения

redirect_uri - веб-страница на которую вы будете переадресованы после того как пользователь разрешил доступ к своим данным

scope  - это области пользовательских данных, на которые мы будем просить разрешения у пользователя. Помните мы настраивали их в окне аутентификации. Задаются в качестве текстовой строки через пробел.

response_type - тип возвращаемого кода,задаётся как code, и означает вернуть аутентификационный код  в параметрах запроса при переадресации на страницу redirect_uri, после того  как пользователь нажмёт разрешить на доступ к своим данным.

Есть также и другие параметры но значение по умолчанию этих параметров нас вполне устраивает, подробнее можно почитать здесь(англ.)

Кнопка Авторизация  содержит код начала процесса авторизации

&НаКлиенте
Процедура Авторизоваться(ОписаниеДействия = Неопределено)
	
	ПараметрыФормы = новый структура("Адрес", АдресСтраницыАутентификации());
	ОО = Новый ОписаниеОповещения("ОбработатьAccessToken", ЭтаФорма, ОписаниеДействия);		
	ОткрытьФорму("ВнешняяОбработка.АутентификацияGoogle.Форма.ФормаАутентификации", ПараметрыФормы, Элементы.Авторизоваться, ,,,ОО, РежимОткрытияОкнаФормы.БлокироватьОкноВладельца);
	
КонецПроцедуры

 Мы просто открываем вспомогательную форму авторизацию с одним параметром - адресом страницы аутентификации, который формирует для нас функция:

&НаКлиентеНаСервереБезКонтекста
Функция АдресСтраницыАутентификации()

	ПараметрыURL = Новый Структура;
	Адрес = "https://accounts.google.com/o/oauth2/v2/auth";
	ПараметрыURL.Вставить("client_id", "<ваш уникальный идентификатор приложения из Google API console>.apps.googleusercontent.com");
	ПараметрыURL.Вставить("redirect_uri", "http://localhost");
	ПараметрыURL.Вставить("scope", "https://www.googleapis.com/auth/calendar.readonly https://www.googleapis.com/auth/calendar.events.readonly  https://www.googleapis.com/auth/calendar");
	ПараметрыURL.Вставить("response_type", "code");
	ПараметрыURL.Вставить("prompt", "consent"); //Пользователю отображается только окно разрешения доступа к его пользовательским данным
	Возврат Адрес(Адрес, ПараметрыURL);

КонецФункции // ПолучитьAuthToken()

В результате работы кода кнопки открывается окно аутентификации. После того как пользователь нажал кнопку Allow(разрешить), сервер Google перенаправит нас на страницу указанную при регистрации приложения - http://localhost, которая попытается открыться в том же поле HTML Документа, но скорее всего не сможет, если у вас не запущен локальный веб-сервер. В обработчике события поля HTML документа мы извлечём полученный код аутентификации.

Ниже показан код формы, в котором нам нужно извлечь аутентификационный код из параметров командной строки, так как 1С не предоставляет возможности в случае localhost обработать параметры адресной строки(напишите в комментариях, если существует способ), но отображает адрес страницы редиректа в теле полеHTML документа, то код извлекаем из тела страницы.
 


&НаКлиенте
Процедура ПолеHTMLДокументСформирован(Элемент)
	
	Адрес = Элемент.Документ.URL;
	if Адрес = "about:blank" Then
		InnerHTML = Элемент.Документ.body.InnerHTML;
		AuthCode = AuthCode(InnerHTML);
		Закрыть(AuthCode);
	endif

КонецПроцедуры

&НаКлиентеНаСервереБезКонтекста
Функция AuthCode(URL)
	НачалоКода = СтрНайти(ВРЕГ(URL), ВРЕГ("code="), НаправлениеПоиска.СНачала);
	Если НачалоКода = 0 Тогда
		Возврат "";
	КонецЕсли;
	НачалоКода = НачалоКода + 5;
	КонецКода = СтрНайти(ВРЕГ(URL), ВРЕГ("&amp;"), НаправлениеПоиска.СНачала, НачалоКода); 
	Возврат Сред(URL, НачалоКода, КонецКода - НачалоКода);
КонецФункции

&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
	Адрес = Параметры.Адрес;
КонецПроцедуры




На основную форму возвращаем код аутентификации который позволит нам обменять его на токен доступа на следующем этапе еще одним запросом к серверу.

Второй этап. Полученный код следует обменять на токен доступа(Access token). Токен доступа это идентификатор который выдаётся авторизационным сервером приложению на определенный промежуток времени для доступа к данным пользователя. Запрос выполняется методом POST со следующими параметрами.

code - полученный авторизационный код

client_id - идентификатор приложения из Console APi Goolge

client_secret - секретный код приложения из Console APi Google

redirect_uri - адрес переадресации указанный в Console APi Google

grant_type - содержит значение authorization_code

&НаКлиенте
Процедура ОбработатьAccessToken(AuthCode, ОписаниеДействия) Экспорт

	Если AuthCode <> Неопределено И Не ПустаяСтрока(AuthCode) Тогда
		Tokens = Tokens(AuthCode);
		AccessToken = AccessToken(Tokens);
		RefreshToken = ?(RefreshToken(Tokens) = Неопределено, RefreshToken, RefreshToken(Tokens));
		Календари = ЗаполнитьКалендари(AccessToken);
		ЗаполнитьКалендариНаФорме(Календари);
		ПоказатьОповещениеПользователя("Авторизация успешна",,,,СтатусОповещенияПользователя.Информация);
		Если ОписаниеДействия <> Неопределено Тогда
			СтрокаВыполнить = ОписаниеДействия.Действие + "(" + AccessToken + "," + ОписаниеДействия.ПараметрыДействия + ")";
			Выполнить(СтрокаВыполнить);
		КонецЕсли;
	Иначе
		AccessToken = "";
	КонецЕсли;

КонецПроцедуры // ОбработатьAccessToken()

&НаКлиентеНаСервереБезКонтекста
Функция AccessToken(Tokens)
	
	Если типЗнч(Tokens ) = Тип("Структура") Тогда
		Возврат Tokens.access_token;
	Иначе
		Возврат Неопределено;
	КонецЕсли;
	
КонецФункции // AccessToken()

&НаКлиентеНаСервереБезКонтекста
Функция RefreshToken(Tokens)

	Если Tokens.Свойство("refresh_token") Тогда
		Возврат Tokens.refresh_token;
	Иначе
		Возврат Неопределено;
	КонецЕсли;

КонецФункции // RefreshToken()

&НаСервереБезКонтекста
Функция Tokens(AuthCode)
	
	ПараметрыURL = Новый Структура;
	АдресЗапроса = "https://www.googleapis.com/oauth2/v4/token";
	ПараметрыURL.Вставить("client_id", "<ваш идентификатор приложения из Google API Console>.apps.googleusercontent.com");
	ПараметрыURL.Вставить("redirect_uri", "http://localhost");
	ПараметрыURL.Вставить("code", AuthCode);
	ПараметрыURL.Вставить("client_secret", "<ваш secret key>");
	ПараметрыURL.Вставить("grant_type", "authorization_code");
	
	АдресЗапроса = Адрес(АдресЗапроса, ПараметрыURL);
	СтруктураURI = СтруктураURI(АдресЗапроса);
	HTTPСоединение = новый HTTPСоединение(СтруктураURI.Хост,443 , , ,, 15, Новый ЗащищенноеСоединениеOpenSSL);
	headers = Новый Соответствие;
	headers.Вставить("User-Agent", "Mozilla");
	headers.Вставить("Host", СтруктураURI.Хост);
	headers.Вставить("Content-Type", "application/x-www-form-urlencoded");
	HTTPЗапрос = Новый HTTPЗапрос(СтруктураURI.ПутьНаСервере, headers);
	HTTPОтвет = HTTPСоединение.ОтправитьДляОбработки(HTTPЗапрос);
	Если HTTPОтвет.КодСостояния = 200 Тогда
		Ответ = HTTPОтвет.ПолучитьТелоКакСтроку();
		ЧтениеJSON = новый ЧтениеJSON();
		ЧтениеJSON.УстановитьСтроку(Ответ);
		 Token = ПрочитатьJSON(ЧтениеJSON, Ложь);
		 Возврат Token;
	 Иначе
		 ВызватьИсключение "Произошла ошибка обращения к серверу," + "Токен не получен" +
		 Символы.ПС + "Статус ответа сервера: " + HTTPОтвет.КодСостояния;
	КонецЕсли;
	
КонецФункции
&НаСервереБезКонтекста
Функция Адрес(Знач URL, Знач ПараметрыURL)
	
	Перем МассивПараметров;
	МассивПараметров = Новый Массив;
	Для каждого Параметр Из ПараметрыURL Цикл
		МассивПараметров.Добавить(Параметр.Ключ + "=" + Параметр.Значение);
	КонецЦикла;
	URL = СокрП(URL);
	URL = ?(СтрЗаканчиваетсяНа(URL, "/"), URL, URL + "/"); 
	Возврат URL + "?" + КодироватьСтроку(СтрСоединить(МассивПараметров, "&"),	СпособКодированияСтроки.URLВКодировкеURL);

КонецФункции

В коде отправляем подготовленный POST-запрос и в случае успешного результата, получаем JSON ответ с токеном доступа(access token) и токеном обновления, который мы можем использовать при повторном запросе токена доступа когда действующий токен доступа истечёт.

На этом авторизация завершена, пришло время воспользоваться пройденной авторизацией и получить что-нибудь полезное.

Третий этап.

Имея токен доступа в получим список календарей и события выбранного календаря.

&НаКлиенте
Процедура ЗаполнитьКалендариНаФорме(Календари)

	Элементы.КалендариGoogle.СписокВыбора.Очистить();
	Если Календари.items.Количество() > 0 Тогда
		Для Каждого Календарь Из Календари.items Цикл	
			Элемент = Элементы.КалендариGoogle.СписокВыбора.Добавить(Календарь.id, Календарь.summary);	
		КонецЦикла;
		КалендариGoogle = Элементы.КалендариGoogle.СписокВыбора.Получить(0).Значение;
		КалендариGoogleПриИзменении(Неопределено);
	КонецЕсли;
	
КонецПроцедуры 

Функция ЗаполнитьКалендари(AccessToken)

	Возврат ПолучитьСписокКалендарей(AccessToken);
	
КонецФункции

Функция ПолучитьСписокКалендарей(AccessToken)
	
	ПараметрыURL = Новый Структура;
	АдресЗапроса = "https://www.googleapis.com/calendar/v3/users/me/calendarList";
	
	СтруктураURI = СтруктураURI(АдресЗапроса);
	HTTPСоединение = новый HTTPСоединение(СтруктураURI.Хост,443 , , ,, 15, Новый ЗащищенноеСоединениеOpenSSL);
	headers = Новый Соответствие;
	headers.Вставить("User-Agent", "Mozilla");
	headers.Вставить("Host", "www.googleapis.com");
	headers.Вставить("Content-Type", "application/x-www-form-urlencoded");
	headers.Вставить("Authorization", "Bearer " + AccessToken);
	headers.Вставить("Accept", "application/json");
	HTTPЗапрос = Новый HTTPЗапрос(СтруктураURI.ПутьНаСервере, headers);
	HTTPОтвет = HTTPСоединение.Получить(HTTPЗапрос);
	Если HTTPОтвет.КодСостояния = 200 Тогда
		Ответ = HTTPОтвет.ПолучитьТелоКакСтроку();
		ЧтениеJSON = новый ЧтениеJSON();
		ЧтениеJSON.УстановитьСтроку(Ответ);
		Календари = ПрочитатьJSON(ЧтениеJSON, ЛОжь);
		 Возврат Календари;
	 Иначе
		 ВызватьИсключение "Произошла ошибка обращения к серверу," + "Токен не получен" +
		 Символы.ПС + "Статус ответа сервера: " + HTTPОтвет.КодСостояния;
	КонецЕсли;
	
КонецФункции

&НаКлиенте
Функция ПолучитьСписокСобытий(Знач AccessToken,Знач ИдКалендаря)
	
	ПараметрыURL = Новый Структура;
	АдресЗапроса = "https://www.googleapis.com/calendar/v3/calendars/{ИдКалендаря}/events";
	ИдКалендаря = КодироватьURI(ИдКалендаря);
	АдресЗапроса = СтрЗаменить(АдресЗапроса, "{ИдКалендаря}", ИдКалендаря); 
	ПараметрыURL = Новый Структура;
	ПараметрыURL.Вставить("key", "<Секретный ключ клиента>");
	
	АдресЗапроса = Адрес(АдресЗапроса, ПараметрыURL);
	
	СтруктураURI = СтруктураURI(АдресЗапроса);
	HTTPСоединение = новый HTTPСоединение(СтруктураURI.Хост,443 , , ,, 15, Новый ЗащищенноеСоединениеOpenSSL);
	headers = Новый Соответствие;
	headers.Вставить("Host", СтруктураURI.Хост);
	headers.Вставить("Content-Type", "application/x-www-form-urlencoded");
	headers.Вставить("Authorization", "Bearer " + AccessToken);
	headers.Вставить("Content-length", "0");
	headers.Вставить("Accept", "application/json");
	HTTPЗапрос = Новый HTTPЗапрос(СтруктураURI.ПутьНаСервере, headers);
	HTTPОтвет = HTTPСоединение.Получить(HTTPЗапрос);
	Если HTTPОтвет.КодСостояния = 200 Тогда
		Ответ = HTTPОтвет.ПолучитьТелоКакСтроку();
		ЧтениеJSON = новый ЧтениеJSON();
		ЧтениеJSON.УстановитьСтроку(Ответ);
		 СобытияКалендаря = ПрочитатьJSON(ЧтениеJSON, Истина);
		 Возврат СобытияКалендаря;
	 ИначеЕсли HTTPОтвет.КодСостояния = 401 Тогда
		 ЧтениеJSON = Новый ЧтениеJSON;
		 ЧтениеJSON.УстановитьСтроку(HTTPОтвет.ПолучитьТелоКакСтроку());
		 ОтветJSON = ПрочитатьJSON(ЧтениеJSON, ЛОЖЬ);
		 Если ОтветJSON.error.message = "Invalid Credentials" Тогда
			 //Обновить Token
			 AccessToken = AccessToken(ОбновитьТокен(RefreshToken));
			 Если ЗначениеЗаполнено(AccessToken) Тогда
				 Возврат ПолучитьСписокСобытий(AccessToken, ИдКалендаря);
			 Иначе
				 ПоказатьОповещениеПользователя("Необходима авторизация",,,,СтатусОповещенияПользователя.Информация);
				 ПараметрыДействия = Новый Массив;
				 ПараметрыДействия.Добавить(ИдКалендаря);
				 Авторизоваться(ОписаниеДействия("ПолучитьСписокСобытий", ПараметрыДействия));
			 КонецЕсли;
		 КонецЕсли;

	КонецЕсли;
	

КонецФункции

&НаКлиентеНаСервереБезКонтекста
Функция ОбновитьТокен(RefreshToken)

	Если Не ПустаяСтрока(RefreshToken) Тогда
		Возврат RefreshTokens(RefreshToken);
	Иначе
		Возврат Неопределено;
	КонецЕсли;

КонецФункции

&НаСервереБезКонтекста
Функция RefreshTokens(RefreshToken)
	
	ПараметрыURL = Новый Структура;
	АдресЗапроса = "https://www.googleapis.com/oauth2/v4/token";
	ПараметрыURL.Вставить("client_id", "<идентификатор приложения>.apps.googleusercontent.com");
	ПараметрыURL.Вставить("redirect_uri", "http://localhost");
	ПараметрыURL.Вставить("refresh_token", RefreshToken);
	ПараметрыURL.Вставить("client_secret", "<секретный ключ>");
	ПараметрыURL.Вставить("grant_type", "refresh_token");
	
	АдресЗапроса = Адрес(АдресЗапроса, ПараметрыURL);
	СтруктураURI = СтруктураURI(АдресЗапроса);
	HTTPСоединение = новый HTTPСоединение(СтруктураURI.Хост,443 , , ,, 15, Новый ЗащищенноеСоединениеOpenSSL);
	headers = Новый Соответствие;
	headers.Вставить("User-Agent", "Mozilla");//google-oauth-playground
	headers.Вставить("Host", СтруктураURI.Хост);
	headers.Вставить("Content-Type", "application/x-www-form-urlencoded");
	HTTPЗапрос = Новый HTTPЗапрос(СтруктураURI.ПутьНаСервере, headers);
	HTTPОтвет = HTTPСоединение.ОтправитьДляОбработки(HTTPЗапрос);
	Если HTTPОтвет.КодСостояния = 200 Тогда
		Ответ = HTTPОтвет.ПолучитьТелоКакСтроку();
		ЧтениеJSON = новый ЧтениеJSON();
		ЧтениеJSON.УстановитьСтроку(Ответ);
		 Token = ПрочитатьJSON(ЧтениеJSON, Ложь);
		 Возврат Token;
	 Иначе
		 ВызватьИсключение "Произошла ошибка обращения к серверу," + "Токен не получен" +
		 Символы.ПС + "Статус ответа сервера: " + HTTPОтвет.КодСостояния;
	КонецЕсли;
	
КонецФункции

&НаКлиенте
Процедура КалендариGoogleПриИзменении(Элемент)
	
	ИдКалендаря = Элементы.КалендариGoogle.СписокВыбора.НайтиПоЗначению(КалендариGoogle);
	СписокСобытий = ПолучитьСписокСобытий(AccessToken, ИдКалендаря.Значение) ;
	События.Очистить();
	Если События = Неопределено Тогда 
		Возврат;
	Конецесли;
	Для каждого Событие Из СписокСобытий["items"] Цикл
		
		Если Событие["start"] ["date"] = Неопределено Тогда
			ДатаСобытия = '00010101';
		Иначе
			ДатаСобытия = ПрочитатьДатуJSON(Событие["start"] ["date"], ФорматДатыJSON.ISO);
		КонецЕсли;
		Если Событие["summary"] = Неопределено Тогда
			ОписаниеСобытия = "";
		Иначе
			ОписаниеСобытия =  Событие["summary"];
		КонецЕсли;
		События.Добавить(ДатаСобытия, ОписаниеСобытия + "("  + Формат(ДатаСобытия, "ДФ=dd.MM.yy") + ")");
	
	КонецЦикла;
КонецПроцедуры

В коде мы формируем пару GET запросов на получение календарей и событий календаря, адреса на которые отправляются запросы определены в документации Google, применительно к API календаря подробнее ознакомиться можно по ссылке здесь(англ.). Обратите особое внимание на заголовок Bearer в запросах в нем мы передаём наш токен доступа. Обязателен также задать заголовок Content-type как в примере. Остальные параметры упоминались ранее.

Стоит прокомментировать этот участок кода, здесь анализируем код ответа. Если в результате запроса получили ошибку "Invalid Credentials", это означает что наш текущий токен доступа истёк, и тогда есть два варианта, или получить новый токен доступа повторно с помощью токена обновления (Refresh token) или запросить у пользователя повторно доступ к его данным через окно авторизации.

Если HTTPОтвет.КодСостояния = 200 Тогда
		Ответ = HTTPОтвет.ПолучитьТелоКакСтроку();
		ЧтениеJSON = новый ЧтениеJSON();
		ЧтениеJSON.УстановитьСтроку(Ответ);
		 СобытияКалендаря = ПрочитатьJSON(ЧтениеJSON, Истина);
		 Возврат СобытияКалендаря;
	 ИначеЕсли HTTPОтвет.КодСостояния = 401 Тогда
		 ЧтениеJSON = Новый ЧтениеJSON;
		 ЧтениеJSON.УстановитьСтроку(HTTPОтвет.ПолучитьТелоКакСтроку());
		 ОтветJSON = ПрочитатьJSON(ЧтениеJSON, ЛОЖЬ);
		 Если ОтветJSON.error.message = "Invalid Credentials" Тогда
			 //Обновить Token
			 AccessToken = AccessToken(ОбновитьТокен(RefreshToken));
			 Если ЗначениеЗаполнено(AccessToken) Тогда
				 Возврат ПолучитьСписокСобытий(AccessToken, ИдКалендаря);
			 Иначе
				 ПоказатьОповещениеПользователя("Необходима авторизация",,,,СтатусОповещенияПользователя.Информация);
				 ПараметрыДействия = Новый Массив;
				 ПараметрыДействия.Добавить(ИдКалендаря);
				 Авторизоваться(ОписаниеДействия("ПолучитьСписокСобытий", ПараметрыДействия));
			 КонецЕсли;
		 КонецЕсли;
		 //ВызватьИсключение "Произошла ошибка обращения к серверу," + "Токен не получен" +
		 //Символы.ПС + "Статус ответа сервера: " + HTTPОтвет.КодСостояния;
		 Сообщить(HTTPОтвет.ПолучитьТелоКакСтроку());
		 Сообщить(AccessToken);
	КонецЕсли;





R03;

Осталось отразить полученные данные на форме, календари в выпадающем списке, а список событий в списке на форме. При выборе календаря предусмотрен обработчик события выбора календаря обновляющего список событий из выбранного календаря.

 

 

К статье прикреплена обработка содержащая полный код описанной в статье обработки. Из обработки удалены зарегистированные мной идентификаторы приложения, перед запуском вам нужно будет зарегистрировать собственное приложение в Google API.

Спасибо за внимание.

OAuth

См. также

Перенос данных из Парус 8 в ЗГУ 3

Зарплата Внешние источники данных Бюджетный учет Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 8 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

84000 руб.

19.08.2020    22447    19    1    

22

Перенос данных из Парус 10 в ЗГУ ред.3

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Обмен между базами 1C Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    9206    9    8    

10

Перенос данных из Парус 7.хх в ЗГУ ред.3

Внешние источники данных Зарплата Бюджетный учет Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 7.хх учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

24000 руб.

24.04.2017    48694    97    163    

86

Перенос начальных остатков из Парус 7.71 в БГУ

Внешние источники данных Взаиморасчеты Учет ОС и НМА Логистика, склад и ТМЦ Бюджетный учет Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 2.0 1С:Бухгалтерия государственного учреждения Государственные, бюджетные структуры Россия Бюджетный учет Платные (руб)

Перенос словарей и начальных остатков из ПП Парус-Бухгалтерия Бюджет 7.71 в 1Сv8 БГУ2. Заполнение словарей и документов по вводу начальных остатков. Не требуется установка ПП Парус7. Возможна дозагрузка. Позволит автоматически и наиболее полно ввести данные в программу для начала работы. 

15600 руб.

08.12.2011    81558    128    123    

147

Перенос данных из Парус 10 (Торнадо) в ЗГУ ред.3 через Excel

Внешние источники данных Загрузка и выгрузка в Excel Зарплата Бюджетный учет Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате из Парус 10(Торнадо) учреждений через файлы Excel в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ). В принципе, обработка может быть использована для загрузки из файлов Excel, полученных из любых информационных систем.

24000 руб.

16.11.2018    29997    20    31    

21

Загрузка спецификаций в УНФ из системы Базис-мебельщик

Производство готовой продукции (работ, услуг) Внешние источники данных Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 Лесное и деревообрабатывающее хозяйство Россия Управленческий учет Платные (руб)

Обработка предназначена для загрузки файлов, выгруженных из системы Базис-мебельщик, в справочник "Спецификации" для последующих процессов учета и диспетчирования полуфабрикатов и изделий.

7200 руб.

24.06.2021    19126    52    50    

29
Отзывы
3. uno-c 234 01.05.19 08:12 Сейчас в теме
(1)
Слишком много действий, только для того чтобы авторизоваться.

Если делать двуногую авторизацию с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать. Автору спасибо за такую длинную подробную статью!
Прикрепленные файлы:
Остальные комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. osivv 265 05.04.19 18:24 Сейчас в теме
Здравствуйте.
Спасибо за статью, но добавлю "ложку дегтя".
Но вроде бы не однократно писалось в интернете, что протокол описываемый вами устарел.
Слишком много действий, только для того чтобы авторизоваться.
Эта схема только для гугла?
В коде 1С используете "структуру", гугл API понимает? В моем способе авторизации она не проходит, возвращается ошибка.
Вроде бы в 1С давно реализована возможность синхронизации с акк гугла, или ошибаюсь?
2. binx 167 05.04.19 18:48 Сейчас в теме
(1)
Слишком много действий, только для того чтобы авторизоваться.

Что поделать, таков протокол.
Эта схема только для гугла?
принцип работы у всех сервисов использующих протокол должна быть одинакова, но естественно что отличия в передаваемых параметрах и заголовках возможно, надо изучать API соответствующих сервисов.
не понял насчет "структуры", напишите на каком этапе у вас не получается. Что за структура?
Вроде бы в 1С давно реализована возможность синхронизации с акк гугла, или ошибаюсь?

Думаю что вы ошибаетесь, Синтаксис помощнике нет функций подключения к Google или к какому либо другому подобному сервису.
Но вроде бы не однократно писалось в интернете, что протокол описываемый вами устарел.

OAuth 2.0 опубликован в 2012 году и насколько мне известно, это последняя редакция этого протокола
4. uno-c 234 01.05.19 08:23 Сейчас в теме
(2)
Думаю что вы ошибаетесь, Синтаксис помощнике нет функций подключения к Google или к какому либо другому подобному сервису
Сейчас под рукой, например, Бухгалтерия предприятия, редакция 3.0.70.30. В ней есть общий модуль СинхронизацияСКалендаремGoogle - там тоже трехногая авторизация используется с помощью идентификатора клиента oAuth. И прямо в коде, кстати, client_id и client_secret, одни на всю страну )
KUAvanesov; +1 Ответить
119. uno-c 234 10.06.20 09:56 Сейчас в теме
(2) Вот здесь немного упростил действия для авторизации, пользуйтесь https://infostart.ru/public/1247448/
3. uno-c 234 01.05.19 08:12 Сейчас в теме
(1)
Слишком много действий, только для того чтобы авторизоваться.

Если делать двуногую авторизацию с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать. Автору спасибо за такую длинную подробную статью!
Прикрепленные файлы:
7. fixin 4252 09.12.19 12:41 Сейчас в теме
(3) гм, а где взять этот ключ сервисного аккаунта? Не для Google? Это поддерживается в протоколе?
8. uno-c 234 09.12.19 13:50 Сейчас в теме
(7)В протоколе поддерживается несколько методов создания подписей: https://ru.wikipedia.org/wiki/OAuth#Методы_создания_подписей

Гугл в своей 2LO ("двуногая авторизация") выбрал RSA-SHA, соответственно Гугл создал возможность сгенерировать/скачать закрытый ключ для сервис-аккаунта.
130. user1597854 18.05.21 19:32 Сейчас в теме
(8) Гугл дал возможность двуногой авторизации, дал сервис-аккаунту (каждому?) свой Google Drive со своими 15 гигабайтами, свои календари и прочее и прочее :)
Я создал сервис-аккаунт и API мне показывает, что Google Drive этого сервис-аккаунта пустой, хотя Google Drive непосредственно моей личной учетки заполнен более, чем на половину. Интересно, сколько сервис-аккаунтов можно насоздавать из одной личной учетки и сколько суммарно бесплатного Google Drive можно таким образом получить зарегистрировав всего одну личную учетку?
10. Apokal1985 27.02.20 08:57 Сейчас в теме
(3) Пример в студию! как подключиться куда стучать?
11. uno-c 234 27.02.20 17:26 Сейчас в теме
12. Pawlick 10 29.05.20 19:56 Сейчас в теме
(3)
Т.е Вы, коллега хотите сказать, что получив магический "ключа сервисного аккаунта" Вы можете получить доступ к Google-данным ЛЮБОГО пользователя без его (пользователя) согласия???
13. uno-c 234 29.05.20 20:34 Сейчас в теме
(12)Если имеете в виду ошибку употребления терминов - то конечно Вы правы. Не двуногая авторизация, а двуногая аутентификация.
14. Pawlick 10 30.05.20 00:24 Сейчас в теме
(13) Нет, я имел ввиду, что никакой супер ключ не даст Вам доступа к пользовательским данным без прямого согласия пользователя. Учетки Google (как и у Майкрософта) бывают двух видов: личные и корпоративные. Доступ к данным личной учетной записи Вы не получите НИКОГДА без прямого согласия пользователя. Доступ к корпоративной учетной записи может дать администратор портала (GSuite от Гугла или Ofice365 от Майкрософта). Тогда прямого согласия пользователя на доступ к его КОРПОРАТИВНЫМ данным не требуется.
16. uno-c 234 30.05.20 07:34 Сейчас в теме
(14) Выше я написал - двуногая аутентификация (не авторизация). Ключ сервисного аккаунта аутентифицирует сервисный аккаунт без участия пользователя. Никаких подтверждений никакого пользователя не требуется в процессе аутентификации сервисной учетки.
17. Pawlick 10 30.05.20 10:46 Сейчас в теме
(16)Если не сложно, приведите пример.

Вернее даже не так.
Вот учетная запись Гугл

andrey.jiivih*gmail.com

Учетка новая. В календаре одно событие. Можете сказать текст этого события?
18. uno-c 234 30.05.20 12:18 Сейчас в теме
(17) Третий раз повторю: в обсуждаемой статье речь об аутентификации, а не об авторизации. Либо Вы невнимательны, либо не понимаете разницы между этими терминами, задавая такой вопрос о Вашем календаре.
Я ошибочно употребил слово авторизация, но обратил внимание на мою ошибку в 13-м посте.
Мой 3-й пост следует читать так: "Если делать двуногую аутентификацию с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать."
19. Pawlick 10 30.05.20 14:29 Сейчас в теме
(18) Не надо мне ничего повторять, коллега. В статье речь идет о получении ДАННЫХ КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ из аккаунта Гугл.э, для получения которых нужно ЯВНОЕ РАЗРЕШЕНИЕ ПОЛЬЗОВАТЕЛЯ. А для этого существует протокол OAuth, парадигма которого подразумевает, что одно приложение (первая нога) хочет получить данные другого приложения (вторая нога), но у данных второй ноги есть владелец (третья нога) и вот эта третья нога должна дать разрешение первой ноги получить данные у второй. Это называется трехногой <неважноКакНазвать>фикацией.
Вы же ответили, что есть способ двуногой <неважноКакНазвать>фикации, при которой с помощью "ключа сервисного аккаунта" можно получить ЛИЧНЫЕ ДАННЫЕ ПОЛЬЗОВАТЕЛЯ, без третьей ноги, т.е собственно пользователя. Вот я и пытаюсь понять как Вы это собираетесь сделать... ) А Вы мне про термины какие то....))
20. uno-c 234 30.05.20 14:54 Сейчас в теме
(19)
Вы же ответили, что есть способ двуногой <неважноКакНазвать>фикации, при которой с помощью "ключа сервисного аккаунта" можно получить ЛИЧНЫЕ ДАННЫЕ ПОЛЬЗОВАТЕЛЯ

Где говорил про "ЛИЧНЫЕ ДАННЫЕ ПОЛЬЗОВАТЕЛЯ"? Не фантазируйте )
Я обозначил метод, которым можно провести двуногую аутентификацию сервисной учетки без участия пользователя, не более. Результатом аутентификации будет access token сервисной учетки. Как использовать access token - это другой вопрос.
21. uno-c 234 30.05.20 15:35 Сейчас в теме
(19) Кстати, в статье нет ни одного слова, начинающегося с личн* и 29 раз встречается access token. Именно о получении acces token методом 2LO без участия пользователя я и вел речь. При использовании 2LO не надо рисовать в 1С формы с WebKit, IE7 и т.п. Просто ставишь цифровую подпись RSA-SHA256, отправляешь HTTP - запрос, получаешь access token - и вперед.
22. Pawlick 10 30.05.20 16:12 Сейчас в теме
(21)Ведите спор честно. Не надо манипулировать понятиями или считать количество определенных слов в тексте статьи. В статье решается конкретная прикладная задача: получение данных Гугл календаря некоего абстрактного пользователя с помощью OAuth протокола. Это и есть те самые ЛИЧНЫЕ ДАННЫЕ (или персональные, не важно) УЧЕТНОЙ ЗАПИСИ КОНЕЧНОГО ПОЛЬЗОВАТЕЛЯ. И для из получения необходимо разрешение пользователя. Вы написали, что пользователь не нужен. Вот я и пытаюсь понять как у Вас это получится.
23. uno-c 234 30.05.20 16:14 Сейчас в теме
(22) Разве мы спорим? Вы задали вопрос, что я имел в виду. Я ответил - что я имел в виду. 2LO аутентифицирует сервис-аккаунт без участия пользоватяля. 2LO получает access token более быстрым путем. Всё. Пользователь не нужен в процессе аутентификации и получения access token.
Конкретную прикладную задачу с календарем я не решал таким путем. Но с конкретной гугл-таблицей работал. Уверен, что с календарем проблем тоже не будет.
А приписывать мне Ваши утверждения про "ЛИЧНЫЕ ДАННЫЕ" - не стОит )
24. Pawlick 10 30.05.20 16:19 Сейчас в теме
(23) Объясните, Ваша конечная цель получить access token? Или получить данные календаря?
25. uno-c 234 30.05.20 16:26 Сейчас в теме
(24) Моя цель - обозначить альтернативу. Статья называется "Аутентификация на внешних сервисах посредством OAuth". В статье описана трехногая аутентификация. Я заметил, что можно сделать и двухногую аутентификацию. В процессе двухногой аутентификации не требуется рисовать форму браузера, не требуется подтверждение пользователя - действий меньше. Все что нужно для 2LO аутентификации - скачать в дашборде (https://console.developers.google.com/apis/dashboard) secretkey.json, поставить им цифровую подпись, добавить эту подпись в HTTPЗапрос. В итоге access token получаем путем всего одного HTTPЗапроса.
26. uno-c 234 30.05.20 18:16 Сейчас в теме
(22)
Не надо манипулировать понятиями

Понятиями я не манипулирую, я стараюсь использовать понятия согласно их предназначению. Права доступа не имеют отношения к аутентификации. Права доступа - это из области авторизации.
А вот Вы, похоже, занимаетесь https://ru.wikipedia.org/wiki/Демагогия#Подмена_тезиса - когда приписываете мне утверждение, которое я не делал. Имею в виду Вашу фразу, что якобы я утверждал нечто подобное:
Вы же ответили, что есть способ двуногой <неважноКакНазвать>фикации, при которой с помощью "ключа сервисного аккаунта" можно получить ЛИЧНЫЕ ДАННЫЕ ПОЛЬЗОВАТЕЛЯ, без третьей ноги, т.е собственно пользователя.

А я нигде не утверждал про эти Ваши ЛИЧНЫЕ ДАННЫЕ.
128. user1597854 17.05.21 15:37 Сейчас в теме
(13)
ошибку употребления терминов
О нет, вы НЕ ошиблись. В документации https://developers.google.com/identity/protocols/oauth2 написано

На этой странице представлен обзор сценариев авторизации OAuth 2.0, которые поддерживает Google
Сценарии
Приложения веб-сервера
...
Установленные приложения
...
Клиентские (JavaScript) приложения
...
Приложения на устройствах с ограниченным вводом
...
Сервисные аккаунты

В сценарии авторизации "Сервисные аккаунты"
...
В этих ситуациях ваше приложение должно подтвердить свою личность для API, но согласие пользователя не требуется.
...
Ваше приложение вызывает API Google от имени учетной записи службы, и согласие пользователя не требуется.
...

Короче инструкция утверждает, что сценарий "Сервисные аккаунты" - это сценарий OAuth 2.0 АВТОРИЗАЦИИ, при которой НЕ ТРЕБУЕТСЯ СОГЛАСИЕ ПОЛЬЗОВАТЕЛЯ.
131. uno-c 234 19.05.21 08:40 Сейчас в теме
(128) Да, Вы верно подметили - это действительно авторизация без участия пользователя.
Поясню. Прямой ответ на вопрос (12) pawlick-а настолько банален, насколько примитивен сам вопрос о супер-пупер-доступе. Дабы направить беседу в русло познания, я написал, будто ошибся в употреблении терминов. Собеседник, начав с пренебрежения терминами "неважнокак*фикации", постепенно пришел к пониманию, что оспаривал мой тезис а-ля "вода мокрая" или "масло масляное". Но суть познавательно-скорректированного тезиса и его аналогичность "маслу масляному" видна только владеющему терминологией. К сожалению, в терминологии pawlick окончательно не разобрался - в отличие от Вас, в итоге он опрометчиво согласился, что мое утверждение (3) ошибочно.
132. uno-c 234 19.05.21 08:47 Сейчас в теме
(128) В API Google есть интересные фичи с полезными данными, которые можно получить после авторизации сервис-аккаунта без участия пользователя. Вы уже заметили собственный гугл диск у сервис-аккаунта с 15 гигами и собственный календарь. У него также могут быть собственные таблицы и т.п. А чтобы сервис-аккаунт получил доступ к чужому календарю (чужим для него будет даже календарь создателя сервис-аккаунта) - очевидно, что владельцу календаря нужно поуправлять правами доступа. Общедоступность календаря не требуется - достаточно добавить сервис-аккаунт в раздел "Доступ для отдельных пользователей".
133. Pawlick 10 19.05.21 12:46 Сейчас в теме
(132)
А чтобы сервис-аккаунт получил доступ к чужому календарю ... ... очевидно, владельцу календаря нужно поуправлять правами доступа


Да ну?! Да неужели?! И в какой момент Вам стало это "очевидно", коллега, не подскажете?

Мы то тут все с утра думали что:

Ключ сервисного аккаунта аутентифицирует сервисный аккаунт без участия пользователя. Никаких подтверждений никакого пользователя не требуется


штудируем формулировки Gogle Api, что бы, значить, "правильно мысли формулировать"...

Вот и понятие "согласие" на википедИи прочли: "Согласие - это положительный ответ на предложение, запрос, утверждение".

Но вы тут используете термин "поуправлять правами", так что не волнуйтесь, буквоеды сего мира спят спокойно:
"поуправлять правами" это же одно и тоже что "дать согласие" предоставить на доступ к своим данным.
134. uno-c 234 19.05.21 12:52 Сейчас в теме
(133) Вам не надоело рассказывать, что солнце встает на востоке? Ну приторная банальность. Очевидно это всем - не думаю, что в здравом уме у кого-то возникнет предположение, что гугл позволит некоему чужому сервис-аккаунту получить доступ к календарю пользователя без согласия этого пользователя )

Двуногая авторизация сервис-аккаунта действительно происходит без участия пользователя, написано в инструкции и проверено на практике. К своему календарю или своему гугл-диску сервис аккаунт имеет доступ безо всяких "дать согласие" и "поуправлять правами" со стороны какого бы то ни было пользователя - после успешной двуногой авторизации.
27. uno-c 234 31.05.20 13:51 Сейчас в теме
(12) Итак, подытожим
Т.е Вы, коллега хотите сказать, что получив магический "ключа сервисного аккаунта" Вы можете получить доступ к Google-данным ЛЮБОГО пользователя без его (пользователя) согласия???

Процесс аутентификации не решает вопросы предоставления прав доступа - это по определению термина "аутентификация". За предоставление прав доступа отвечает процесс авторизации. Поэтому, после того как я исправил мою ошибку (аутентификация, а не авторизация сервисного аккаунта) - Ваш вопрос стал неуместен, а дальнейшее повторение Ваших домыслов - превратились в демагогию.

Мораль. Не следует относиться к терминам как к чему-то неважному.
двуногой <неважноКакНазвать>фикации
Пренебрежительное отношение к терминологии, незнание, подмена терминов - все это приводит к непониманию.
28. Pawlick 10 31.05.20 17:57 Сейчас в теме
(27) Коллега, сегодня не могу Вам достойно ответить. Подытожим завтра.
29. Pawlick 10 31.05.20 18:07 Сейчас в теме
А пока, можем добавить немного конструктива.
В статье описан процесс получения доступа (авторизации) к данным пользователя, находящемся в аккаунте гугл с помощью трехногой авторизации по протоколу OAuth.
В своем комментарии Вы сказали, что это эту задачу можно решить проще: с помощью двуногой аутентификации, без согласия пользователя.

Если у Вас есть время, в это прекрасное воскресенье, ответьте все таки на вопрос: как Вы собираетесь это сделать. Желательно пошагово. Если нет сегодня - ответьте когда будет удобно. Но ответить надо обязательно.
30. uno-c 234 01.06.20 04:32 Сейчас в теме
(29) Кому надо обязательно? Вам оно зачем ? Ленитесь пару предложений определения термина "аутентификация" прочитать, а в описании двуногой совсем много буков )
Ну на всякий случай, вдруг одумаетесь. Инструкция по двуногой аутентификации:

краткое описание с картинкой - https://developers.google.com/identity/protocols/OAuth2#serviceaccount
подробное - https://developers.google.com/identity/protocols/OAuth2ServiceAccount

Я не собираюсь это делать, я это сделал пару лет назад - по приведенной выше инструкции гугла. Никаких подтверждений пользователя в процессе аутентификации не понадобилось - проверенный факт.
31. Pawlick 10 01.06.20 14:12 Сейчас в теме
(30)Коллега, я вернулся! )

Мораль. Не следует относиться к терминам как к чему-то неважному.


Морали мне читать вздумали?! Чудненько...
Ну что, начнем?

Разве мы спорим?

Да, мы спорим. И суть нашего спора в следующем: я утверждаю, что Вы не сможете получить доступ к данным пользователя через Google API без его явного согласия пользователя, а Вы утверждаете обратное.
Моя цель - обозначить альтернативу

Обозначайте. Вас об этом уже ДВА раза просили: *Apokal1985 в (10) и я в (14). Пока без результатов.
говорил про "ЛИЧНЫЕ ДАННЫЕ ПОЛЬЗОВАТЕЛЯ"? Не фантазируйте)

Это Ваша главная ошибка. Вы о них не говорили, потому, что не понимаете что это такое.
Все потому, что 2018 году Вы написали статью 805071, где открыли доступ СВОЕЙ СОБСТВЕННОЙ сервисной учетной записи к СВОЕЙ СОБСТВЕННОЙ Google таблице. При этом в заголовке статьи Вы позволяете себе использовать фразу «не требует подтверждения пользователя». А так ли это на самом деле?
Вот Ваша цитата из Вашей статьи:
«...не забудьте расшарить доступ к объектам гугла, которые Вы хотите изменять или читать через API. Доступ нужно предоставлять емейлу Вашей сервисной учетной записи.»
Стоп, стоп, стоп: что там надо «расшарить» для того, что бы Ваша сервисная учетка получила доступ к Вашей таблице? «доступ к Вашим объектам гугла»?... «не требует подтверждения пользователя», говорите???
я это сделал пару лет назад Никаких подтверждений пользователя в процессе аутентификации не понадобилось - проверенный факт

Ничего подобного. Вы предварительно «расшарили доступ к своим объектам гугла», таким образом предоставили явное разрешение на доступ сервисной учетной записи к своим собственным данным. А потом назвали свое ноу хау «доступ к Вашим объектам гугла» «не требующем подтверждения пользователя»...

И хватить мне сыпать ссылками, содержание которых Вы прочитали, но смысла который не понимаете. Я "не поленился" это прочесть, и прекрасно приманю разницу между Авторизацией и Аутентификацией. Вот первые два параграфа этой ссылки:
«Система Google OAuth 2.0 поддерживает межсерверные взаимодействия, такие как взаимодействие между веб-сайтами, приложениями и сервисом Google. Для этого сценария вам потребуется учетная запись службы, которая, которая принадлежит вашему приложению, а не отдельному конечному пользователю. Ваше приложение вызывает Google API от имени учетной записи службы, поэтому пользователи не являются непосредственно вовлеченными. Этот сценарий иногда называют "двуногий OAuth" или "2LO" (Соответствующий термин "трехногий OAuth" относится к сценариям, в которых ваше приложение вызывает API Google от имени конечных пользователей, и в которых требуется согласие пользователя.)
Как правило, приложение использует учетную запись службы, когда приложение использует Google API для работы со своими собственными данными, а не с данными пользователя. Например, приложение, которое использует Google Cloud для обеспечения сохраняемости данных будет использовать учетную запись службы для проверки подлинности своих вызовов к Google Cloud Datastore API.»

Вы понимаете о чем это? Это про случай, когда "когда приложение использует Google API для работы со своими собственными данными, а не с данными пользователя".
Вы же умудрились, после прочтения сего смешать бульдога с носорогом, и вкрутить двуногую авторизацию, туда, где должна использоваться треногая. При этом Вам все равно не удалось получить доступ к данным без явного разрешения, но Вы с маниакальным упорством продолжаете называть свой способ "по-человечески".

Вам оно зачем ?

Мне это затем, что «вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие-то советы космического масштаба и космической же глупости»

А теперь главный вопрос: нужно или нет явное разрешение пользователя на доступ к своим данным при «двуногой» схеме протокола OAuth?
32. uno-c 234 01.06.20 14:24 Сейчас в теме
(31) Вы таки и не удосужились прочитать, чем аутентификация отличается от авторизации. Напрягитесь, это гораздо быстрее, чем писать столь длинные посты )))
Потом вернитесь к моему изначальному утверждению (3) с учетом поправки (13), на которое был Ваш первый вопрос. Хотя, проще будет повторить мое утверждение в новой редакции.

Если делать двуногую аутентификацию с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать. Автору спасибо за такую длинную подробную статью!


Мораль: термины надо знать ! Иначе сядешь в лужу )))
33. Pawlick 10 01.06.20 14:27 Сейчас в теме
(32) Вы предоставите пример получения доступа к данным пользователя без его участия, или и дальше будете выкручиваться?
34. uno-c 234 01.06.20 14:28 Сейчас в теме
(33) Ваше незнание что такое атутентификация - это Ваша проблема.
35. Pawlick 10 01.06.20 14:28 Сейчас в теме
(34)Вы предоставите пример получения доступа к данным пользователя без его участия, или и дальше будете выкручиваться?
36. uno-c 234 01.06.20 14:29 Сейчас в теме
(35) Аутентификация не занимается вопросами прав доступа.
37. Pawlick 10 01.06.20 14:31 Сейчас в теме
(36)
Ваши слова?:
Если делать двуногую авторизацию с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать.


Повторяю:

Предоставьте пример получения доступа к данным пользователя без его участия, или и дальше будете выкручиваться?
38. uno-c 234 01.06.20 14:32 Сейчас в теме
(37) Я указал на мою ошибку в первом же ответе (13) на Ваш первый вопрос (12). "Авторизация" я употребил неверно. Нужно читать "аутентификация". Вы невнимательны.
39. Pawlick 10 01.06.20 14:35 Сейчас в теме
(38)
Ваши слова?:
Если делать двуногую АУНТЕФИКАЦИЮ с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать.


Повторяю:

Перестаньте выкручиваться, и предоставьте пример получения доступа к данным пользователя без его участия с помощью двуного АУТЕНТИФИКАЦИИ без участия пользователя.

Либо дайте опровержение своих слов.
40. uno-c 234 01.06.20 14:38 Сейчас в теме
(39) Аутентификация - это не доступы. Доступы - это авторизация. Неужели непонятно?
41. Pawlick 10 01.06.20 14:41 Сейчас в теме
(40)
Учитывая методы ведения Вами диалога, мне, видимо, придется сформулировать свой вопрос так, что бы у Вас не осталось возможностей ответить мне определением «Авторизации» из википедии…

И так:

В статье 1030500 описывается пример получения доступа сторонним Приложением к событиям календаря пользователя из учетной записи Google по протоколу Oauth. В статье сказано, что для этого Приложению необходимо перенаправить пользователя на сервер авторизации Google, где пользователя явно предоставляет право Приложения на доступ к своим данным, после чего Приложение получает токен.
В своем комментарии под статьей под №3 Вы высказали утверждение, из которого следует, что Вам известна более простая («двуногая») процедура получения Приложением , при которой «подтверждение пользователя совсем не нужно запрашивать».
В комментарии №16 Вы еще раз подтвердили, что знаете, как с помощью «сервисного аккаунта» провести процедуру, описанную в статье, при которой «подтверждений никакого пользователя не требуется».
Приведите пример проведения этой процедуры!
Достаточно пошагового описания процесса, без скриншотов.
42. uno-c 234 01.06.20 14:52 Сейчас в теме
(41) Статья называется "Аутентификация на внешних сервисах посредством OAuth". Мой ответ (3) был на реплику (1) ("Слишком много действий")
В (3) я заметил, что есть вариант аутентификации, когда действий поменьше. Употребив неверный термин "авторизация" - возможно, кого-то я ввел в заблуждение. В (13) я исправил свою ошибку, но Вам это не помогло, увы. Все повторяете и повторяете свой неуместный вопрос.
44. Pawlick 10 01.06.20 15:33 Сейчас в теме
(42)
В статье, которую Вы "экспертно" комментируете, решается совершенно конкретная прикладная задача: получение в 1С событий календаря из учетной записи Google некоего человека с помощью авторизации по протоколу OAuth.

Название статьи "Аутентификация на внешних сервисах посредством OAuth", хотя на самом деле в ней описан процесс "Авторизации".

В первом комментарии сказано
Слишком много действий, только для того чтобы авторизоваться.

Ваш ответ:
Если делать двуногую авторизацию с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать.


И вопрос тут не в терминологии "Аутентификации" и "Авторизации", Ключевое слово тут "для получения доступа к данными" "подтверждение пользователя совсем не нужно запрашивать". Вы ошибаетесь. Но это не главное. Мы все ошибаемся время от времени.
Если бы Вы сразу признали свою ошибку, все бы закончилось два дня назад.
А Вы вместо признания совей ошибки мечетесь между формулировками, которые к сути спора не относятся.
Но больше всего меня возмущает Ваш поучительный тон и тот факт, что, для сохранения лица Вы обвиняете в невежестве меня, хотя это именно Вы не поняли сути формулировок протокола, и изобрели велосипед с двуногой авторизацией, там где ПО ДУХУ ПРОТОКОЛА должна была быть применена треногая.
Просто признайте свою ошибку. И Все.
45. uno-c 234 01.06.20 15:36 Сейчас в теме
(44) Для Вас ключевой вопрос - "получение доступа к данным". На практике ключевой вопрос - получение access token (та самая Аутентификация, которая неслучайна в названии статьи). Думаю, не стоит дальше приписывать мне утверждение, которое я не делал* и опровергать его. Или Вам нравится демагогия?
*Вернее сделал, но сразу исправил, как только Вы (12) спросили.
46. Pawlick 10 01.06.20 15:46 Сейчас в теме
(45)
access token

Да что Вы заладили.
Вы своей статье получали "access token" для Аутентификации своего приложения, а человек в статье получает access token для авторизации. Ваша статья и эта про совершенно разные процедуры.
И эта статья про АВТОРИЗАЦИЮ, которую ВЫ НИКОГДА не получите без согласия пользователя.
Мне не нравиться демагогия. Но еще больше мне не нравится типы, которые зубрят протоколы не понимая из истинного смысла, а потом швыряются умными фразами, и обвиняют других.

Я от Вас не отстану: либо подтверждайте мою правоту, либо отвечайте на (41)
47. uno-c 234 01.06.20 15:49 Сейчас в теме
(46) Статья называется "Аутентификация ...". - про аутентификацию я и писал. Есть еще вопросы?
48. Pawlick 10 01.06.20 15:50 Сейчас в теме
49. uno-c 234 01.06.20 15:57 Сейчас в теме
(48)Ответ:
Поскольку я писал только про аутентификацию сервисной учетки без участия пользователя - вопрос (41) неуместен.
50. Pawlick 10 01.06.20 16:00 Сейчас в теме
(49)
Это Ваш комментарий в 3 неуместен к этой статье
51. uno-c 234 01.06.20 16:02 Сейчас в теме
(50) Автор статьи думает иначе )
Если попробуете с нуля, глядя только в инструкции гугла, получить access token - то Вы согласитесь с автором.
52. Pawlick 10 01.06.20 16:06 Сейчас в теме
(51)
Это потому, что Вы и Автора статьи ввели в заблуждение своими безграмотным манипулированием терминологий.

Вот поэтому мой вопрос в 41 остается в силе.

А когда Вы не сможете получить доступа к данным пользователя без его согласия (а Вы не сможете) - вот тогда и посмотрим что думает Автор.
54. uno-c 234 01.06.20 16:13 Сейчас в теме
(52) Доступ дается в один прием) Причем для сервисной учетки его порой удобнее давать. При модели аутентификации данной статьи - для каждого пользователя, к данным которого Вы хотите доступ - нужно инициировать полную описанную процедуру получения code, access token и refresh token, все это запоминать и хранить в разрезе пользователей, давших доступ. Для сервисной учетки - единый secretkey.json, и простое расшаривание ресурсов каждым пользователем, к данным которого необходим доступ Вашему приложению.
56. Pawlick 10 01.06.20 16:16 Сейчас в теме
(54)
простое расшаривание ресурсов каждым пользователем


Так, что требует доступ к ресурсу подтверждения пользователем или нет?
57. uno-c 234 01.06.20 16:19 Сейчас в теме
(56) Аутентификация сервисной учетки не требует подтверждения пользователя - это мой тезис.
Доступ - это не аутентификация, а авторизация.
58. Pawlick 10 01.06.20 16:21 Сейчас в теме
(57) Главный тезис здесь - получения данных с внешнего сервиса, которые Вы не сможете сделать просто аутентифицировав сервисную учетку.
59. uno-c 234 01.06.20 16:23 Сейчас в теме
(58) Ну это для Вас. Для меня главный тезис - первое слово в заголовке статьи.
60. Pawlick 10 01.06.20 16:24 Сейчас в теме
(59)
Это называется "слышал звон да не знаю где он"
61. uno-c 234 01.06.20 16:24 Сейчас в теме
(60) Это называется - попробуй сам и поймешь, что главное.
62. Pawlick 10 01.06.20 16:27 Сейчас в теме
(61)
У меня работающая служба синхронизации календарей с Google API, и Microsoft Grapf.
Так что давно уже все попробовал...
63. uno-c 234 01.06.20 16:28 Сейчас в теме
64. uno-c 234 01.06.20 16:34 Сейчас в теме
(62)Тем не менее примерно 70% этой статьи посвящено именно получению access token. Думаю, автор со мной согласится - аутентификация это главное в статье. Неспроста она так озаглавлена.
Уверен, что календарь автор использовал для проверки результата аутентификации и авторизации, поскольку даже не вынес слово "календарь" в заголовок.
66. Pawlick 10 01.06.20 17:20 Сейчас в теме
(64) "примерно 70% этой статьи посвящено именно получению access token" не для получения access token, а для получения данных с внешнего сервиса, что и указано в заголовке статьи.
Тех самых данных, которые Вы своим велосипедом из 805071 из глупым комментарием (3) без согласия пользователя не получите никогда.
67. uno-c 234 01.06.20 17:23 Сейчас в теме
(66)
У нас разные заголовки статьи? У меня такой: "Аутентификация на внешних сервисах посредством OAuth"

Я и не собирался получать данные без согласия пользователя. Без согласия пользователя я аутентифицировал сервисную учетку.

Как Вы все-таки невнимательны!
70. Pawlick 10 01.06.20 17:28 Сейчас в теме
(67)
Я в отличие от Вас читаю статьи дальше заголовков.
"Пример подключения к сервисам Google из 1С с помощью протокола OAuth и получения данных с внешнего сервиса."


И access token который получали Вы для аутентификации своей статье и access token который получает тут Автор для авторизации - для одной и тоже цели - получение данных с внешнего сервиса. Тех самых данных, которые Вы своим велосипедом из 805071 из глупым комментарием (3) без согласия пользователя не получите никогда.
71. uno-c 234 01.06.20 17:30 Сейчас в теме
(70) Тогда Вы плохо следите за корректностью выражений
для получения данных с внешнего сервиса, что и указано в заголовке статьи.


И прекращайте уже опровергать то, что я не утверждал. Демагог.
72. Pawlick 10 01.06.20 17:33 Сейчас в теме
(71)

Все что Вы утверждали, указано в 41
73. uno-c 234 01.06.20 17:34 Сейчас в теме
(72) То, что указано в 41 называется - Ваши ошибочные домыслы ввиду незнания термина "Аутентификация". Ну или ввиду невнимательности и наплевательского отношения к употреблению терминов.
74. Pawlick 10 01.06.20 17:35 Сейчас в теме
99. uno-c 234 02.06.20 05:47 Сейчас в теме
(74) Время показало: с чужими календарями сервисная учетка работает. Теперь это проверенный факт.
75. Pawlick 10 01.06.20 17:43 Сейчас в теме
(73) В статье несмотря на ее название описан процесс АВТОРИЗАЦИИ, чего Вы, о "всезнающий", в (3) так и не поняли. Как и не поняли смысла протокола OAuth, иначе бы не городили огороды с сервисными учетками
76. uno-c 234 01.06.20 17:45 Сейчас в теме
(75) Понимание аутентификация/авторизация еще не полностью к Вам пришло. В статье есть и процесс аутентификации и процесс авторизации. Найдете соответствующие места или подсказать?
78. Pawlick 10 01.06.20 17:58 Сейчас в теме
(76)
Не надо мне ничего показывать и рассказывать, пока не ответите на 41.
79. uno-c 234 01.06.20 18:00 Сейчас в теме
(78) Я уже ответил. В 41 - Ваши фантазии, я такого не утверждал. Имею в виду в части "получения доступа сторонним Приложением к событиям календаря пользователя".
Все, что я утверждал - сервисная учетка аутентифицируется без участия пользователя.
Или у Вас уже сомнения, что сервисная учетка аутентифицируется без участия пользователя?
77. uno-c 234 01.06.20 17:56 Сейчас в теме
(70)
И access token который получали Вы для аутентификации своей статье и access token который получает тут Автор для авторизации - для одной и тоже цели - получение данных с внешнего сервиса.

Нужно различать цель получения access token и цель написания статьи. Как житейский пример, цель приобретения инструмента - создание изделий. Но цель магазина инструментов - обеспечение людей инструментами. В магазине инструментов крутятся ролики - как круто работает инструмент. Тем не менее цель магазина инструментов - отнюдь не конечное использование инструмента.
Аналогично, цель данной статьи я вижу именно как инструкцию по "добыче" инструмента (получение access token), а в качестве примера - что этим инструментом можно сделать (поработать с календарем)
81. Pawlick 10 01.06.20 18:22 Сейчас в теме
(77)
Дак я Вам о том и пытаюсь сказать. Вы хотели добиться в своей статье? Токен получить, или данные из своей таблицы? Правильно - данные. Вот и Автор в статье получает токен не ради токена, а ради получения данных.
Т.е access token - это средство для достижения цели: получения данных.

Вы оба добились цели - с помощью токена получи данные.Только сделали это разными способами - Вы получили и Аутентификационный токен, а автор Авторизационный.

Вы оба сделали две фундаментальные вещи:
указали апи API, какое именно приложение к ним обращается (аутентифицировали приложения), и указали API их полномочия (авторизовали приложения).

Только Автор сделал это по классической схеме OAuth, а Вы через одно место.
Именно поэтому Ваш совет из 3 никак не поможет Автору получить access token, потому что он не аутентифицирует приложение а авторизует его. Ему не нужен access token для аутентификации, он уже это сделал указав client_id и client_secret.
82. uno-c 234 01.06.20 18:41 Сейчас в теме
(81) Моя статья именно про access token. Получить данные таблицы - это тривиально. Выдать доступ сервисной учетке к таблице или календарю - это супертривиально. А вот токен - это нетривиально (когда на чужой велосипед не подглядываешь). Поэтому что-то мне подсказывает, что в этой статье про трехногую, в ней тоже главное - получение токена.
86. uno-c 234 01.06.20 20:35 Сейчас в теме
(81)
access token, потому что он не аутентифицирует приложение а авторизует его

Вы еще не до конца разобрались с аутентификацией и авторизацией. Ваше утверждение, что треногий access token не аутентифицирует приложение - ошибочно.

Access token из треногой - и аутентифицирует приложение и авторизует его на доступ к календарю.
87. uno-c 234 01.06.20 21:06 Сейчас в теме
(81)
Ваш совет из 3 никак не поможет Автору

Мой совет позволяет получить доступ к календарю альтернативным методом. В совете отсутствует, что нужно сделать для расшаривания календаря под сервисную учетку. Но расшаривание настолько тривиально, что не нужно быть программистом. Когда не пишешь тривиальности - то оставляешь возможность для других чуть-чуть пошевелить мозгами )
53. Pawlick 10 01.06.20 16:11 Сейчас в теме
(51) потому как статья не про получение "access token", А "Пример подключения к сервисам Google из 1С с помощью протокола OAuth и получения данных с внешнего сервиса".

Вот и попробуйте их получить с помощью "двуногого" сценария. А там посмотрим..
55. uno-c 234 01.06.20 16:15 Сейчас в теме
(53) Вот Вы выдумщик. Я не собираюсь пытаться воплощать Ваши фантазии )
65. uno-c 234 01.06.20 16:59 Сейчас в теме
(46)
И эта статья про АВТОРИЗАЦИЮ, которую ВЫ НИКОГДА не получите без согласия пользователя.

Похоже, к Вам приходит понимание, что аутентификация - это не авторизация. Еще не до конца, но прогресс налицо. Надеюсь, теперь мы с Вами не будем путать эти термины )


<неважноКакНазвать>фикации

Как назвать - это важно, поскольку в этих разных терминах - разная суть.
68. Pawlick 10 01.06.20 17:23 Сейчас в теме
(65) в отличии от Вас, понимание, ко мне уже давно пришло задолго до создания Вашего велосипеда и этой статьи,
69. uno-c 234 01.06.20 17:24 Сейчас в теме
(68) Это Вам только кажется, что давно. Иначе бы не разводили демагогию, приписывая мне то, что я не утверждал, многократно повторяя Вашу фантазию, а потом опровергая свои приписки )
80. uno-c 234 01.06.20 18:22 Сейчас в теме
(44)
изобрели велосипед с двуногой авторизацией

А вот эта фраза подсказывает, что Вы не полностью самостоятельно, используя лишь инструкции от гугла, реализовали получение access token. Подглядывали на готовый велосипед? Видимо, поэтому Вам сложно понять, что получение access token - штука не элементарная, и является главной темой обсуждаемой статьи.
83. Pawlick 10 01.06.20 18:45 Сейчас в теме
(80) ну и кто из нас демагог???

Мне вот с самого начала что то подсказывало, что в обеих статьях главное - это получение данных от API Google.
84. uno-c 234 01.06.20 18:52 Сейчас в теме
(83)
ну и кто из нас демагог
Вы в недосягаемости, если количество дем.постов посчитать )

что в обеих статьях главное - это получение данных от API Google
В случае с моей статьей Вы 100% ошиблись, моя статья о нетривиальном. В случае с трехногой - Вы ошиблись, видимо, процентов на 70%. Ну это автору статьи конечно решать )
85. uno-c 234 01.06.20 20:01 Сейчас в теме
(83)
изобрели велосипед с двуногой авторизацией

Так что, Вы все-таки тоже велосипед изобретали, читая инструкцию гугла про трехногую авторизацию и перекладывая ее на язык 1С? Она там рядышком с двуногой лежит, инструкция-то. Или таки воспользовались уже изобретенным велосипедом типа этой статьи?
88. Pawlick 10 01.06.20 21:19 Сейчас в теме
(85)
У Вас иссякают остатки совести и вместимости, коллега.
Ответьте мне на вопрос:
В статье описан процесс авторизации или аутентификации?
89. uno-c 234 01.06.20 21:20 Сейчас в теме
(88) Вопрос неуместен. Как Вы себе представляете авторизацию без аутентификации в контексте обсуждаемого гугл-апи?
Про велосипед Вы не ответили. Сами делали чисто по гугл-документации, или на труды других программистов поглядывали?
90. Pawlick 10 01.06.20 21:45 Сейчас в теме
(89)
Хорошо....

Как в статье происходит аутентификация приложения?
91. uno-c 234 01.06.20 21:46 Сейчас в теме
(90) Напишите сами те места статьи, где как Вы поняли идет аутентификация. Я поправлю и дополню, если ошибетесь.
92. Pawlick 10 01.06.20 21:52 Сейчас в теме
93. uno-c 234 01.06.20 21:53 Сейчас в теме
(92)Все разжевывать - плохая практика. Прилагайте тоже усилия для полного освоения доселе неведомого Вам термина.
И велосипед - как там с ним? Сами или подглядывали?
94. Pawlick 10 01.06.20 21:58 Сейчас в теме
(93)либо отвечайте на вопрос, либо вы пустослов, сударь
95. uno-c 234 01.06.20 22:08 Сейчас в теме
(94) Все в ваших руках. Хотите развиваться - дерзайте, помогу. Одну Вашу ошибку я уже указал, обратили внимание? Трехногий access token - не только авторизует, но и аутентифицирует приложение. Объяснения нужны или сами поняли, в чем Ваша ошибка?
97. Pawlick 10 02.06.20 01:08 Сейчас в теме
(95)
Трехногий access token - не только авторизует, но и аутентифицирует приложение


Покажите, пожалуйста, где Вы это прочли. Только не поленитесь вместо очередной отсылки типа этой показать мне конкретное место в тексте, которые подтверждают Ваши слова.
Оставьте свое сообщение