Аутентификация на внешних сервисах посредством OAuth
Администрирование - Информационная безопасность
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
В данной статье на примере подключения к сервисам 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), ВРЕГ("&"), НаправлениеПоиска.СНачала, НачалоКода);
Возврат Сред(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.
Спасибо за внимание.
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Внешние источники данных Разработчик Аналитик Пользователь 1С:Предприятие 8 1C:Бухгалтерия Узбекистан Беларусь Кыргызстан Молдова Россия Казахстан Платные (руб)
Готовое решение для автоматической выгрузки данных из 1С 8.3 в базу данных ClickHouse, PostgreSQL или Microsoft SQL для работы с данными 1С в BI-системах. «Экстрактор данных 1С в BI» работает со всеми типовыми и нестандартными конфигурациями 1С 8.3 и упрощает работу бизнес-аналитиков. Благодаря этому решению, специалистам не требуется быть программистами, чтобы легко получать данные из 1С в вашей BI-системе.
35000 руб.
15.11.2022 33788 53 49
Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Перенос данных 1C Разработчик 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)
Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактическим удержаниям, НДФЛ, вычетам, страховым взносам из базы Парус 10 учреждений (далее Парус) в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (далее 1С) и начать с ней работать с любого месяца года.
85400 руб.
05.10.2022 14553 17 8
Информационная безопасность Чистка данных Системный администратор Разработчик Руководитель проекта 1С 8.3 1С:Бухгалтерия 3.0 Платные (руб)
Обезличивает копию рабочей базы 1С перед передачей наружу и возвращает настоящие данные обратно, когда база вернулась. Это обратимая псевдонимизация: соответствия «исходное - псевдоним» пишутся в отдельный зашифрованный датасет, который остаётся у владельца. Работает на любой конфигурации - обходит метаданные и находит персональные данные сам, без списка реквизитов под конкретную базу. Суммы, количества, даты и номера документов не трогает никогда, оборотно-сальдовая до и после совпадает до копейки. Проверено на трёх конфигурациях: 106 031 объект, 215 642 замены, ноль ошибок, возврат 100 процентов.
42700 руб.
18.08.2026 1472 3 0
Информационная безопасность Инструменты администратора БД Инструментарий разработчика Учет документов Системный администратор Разработчик Аналитик Бухгалтер Пользователь Руководитель проекта 1С 8.3 1С 8.5 Розничная и сетевая торговля (FMCG) Платные (руб)
Контроль ввода данных в 1С: проверка заполнения реквизитов, обязательные поля, контроль перед записью и проведением, запрет проведения документа. Позволяет настраивать любые проверки данных в 1С 8.3/8.5 от обязательных полей до сложных условий – без открытия конфигуратора и написания кода. Готовое расширение, которое подключается и работает сразу.
6000 руб.
15.04.2026 4148 12 0
Розничная торговля Внешние источники данных Разработчик Бухгалтер 1С:Предприятие 8 1С:Розница 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Розничная и сетевая торговля (FMCG) Бухгалтерский учет Управленческий учет Платные (руб)
Загрузка данных продаж и инкассаций из сервисов Kit Vending/Kit Shop в 1С. Реализовано в виде Расширения. Мониторинг состояний торговых автоматов.
12200 руб.
10.06.2019 34633 49 25
Зарплата Внешние источники данных Бюджетный учет Перенос данных 1C Системный администратор Разработчик 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)
Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактическим удержаниям, НДФЛ, вычетам, страховым взносам из базы Парус 8 учреждений (далее Парус) в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (далее 1С) и начать с ней работать с любого месяца года.
122000 руб.
19.08.2020 30607 28 3
Внешние источники данных Зарплата Бюджетный учет Разработчик Бухгалтер 1С:Предприятие 8 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)
Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактическим удержаниям, НДФЛ, вычетам, страховым взносам из базы Парус 7.хх учреждений (далее Парус) в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (далее 1С) и начать с ней работать с любого месяца года.
85400 руб.
24.04.2017 57637 99 165
Производство готовой продукции (работ, услуг) Внешние источники данных 1С:Предприятие 8 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Лесное и деревообрабатывающее хозяйство Россия Управленческий учет Платные (руб)
Обработка предназначена для загрузки файлов, выгруженных из системы Базис-мебельщик, в справочник 1С "Спецификации" для последующих процессов учета и диспетчирования полуфабрикатов и изделий.
10370 руб.
24.06.2021 26833 66 55
Если делать двуногую авторизацию с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать. Автору спасибо за такую длинную подробную статью!
Спасибо за статью, но добавлю "ложку дегтя".
Но вроде бы не однократно писалось в интернете, что протокол описываемый вами устарел.
Слишком много действий, только для того чтобы авторизоваться.
Эта схема только для гугла?
В коде 1С используете "структуру", гугл API понимает? В моем способе авторизации она не проходит, возвращается ошибка.
Вроде бы в 1С давно реализована возможность синхронизации с акк гугла, или ошибаюсь?
Что поделать, таков протокол.
не понял насчет "структуры", напишите на каком этапе у вас не получается. Что за структура?
Думаю что вы ошибаетесь, Синтаксис помощнике нет функций подключения к Google или к какому либо другому подобному сервису.
OAuth 2.0 опубликован в 2012 году и насколько мне известно, это последняя редакция этого протокола
Если делать двуногую авторизацию с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать. Автору спасибо за такую длинную подробную статью!
Я создал сервис-аккаунт и API мне показывает, что Google Drive этого сервис-аккаунта пустой, хотя Google Drive непосредственно моей личной учетки заполнен более, чем на половину. Интересно, сколько сервис-аккаунтов можно насоздавать из одной личной учетки и сколько суммарно бесплатного Google Drive можно таким образом получить зарегистрировав всего одну личную учетку?
Я ошибочно употребил слово авторизация, но обратил внимание на мою ошибку в 13-м посте.
Мой 3-й пост следует читать так: "Если делать двуногую аутентификацию с помощью ключа сервисного аккаунта (а не с помощью идентификатора клиента oAuth) - то поменьше действий получается, подтверждение пользователя совсем не нужно запрашивать."
Вы же ответили, что есть способ двуногой <неважноКакНазвать>фикации, при которой с помощью "ключа сервисного аккаунта" можно получить ЛИЧНЫЕ ДАННЫЕ ПОЛЬЗОВАТЕЛЯ, без третьей ноги, т.е собственно пользователя. Вот я и пытаюсь понять как Вы это собираетесь сделать... ) А Вы мне про термины какие то....))
Где говорил про "ЛИЧНЫЕ ДАННЫЕ ПОЛЬЗОВАТЕЛЯ"? Не фантазируйте )
Я обозначил метод, которым можно провести двуногую аутентификацию сервисной учетки без участия пользователя, не более. Результатом аутентификации будет access token сервисной учетки. Как использовать access token - это другой вопрос.
Конкретную прикладную задачу с календарем я не решал таким путем. Но с конкретной гугл-таблицей работал. Уверен, что с календарем проблем тоже не будет.
А приписывать мне Ваши утверждения про "ЛИЧНЫЕ ДАННЫЕ" - не стОит )
Понятиями я не манипулирую, я стараюсь использовать понятия согласно их предназначению. Права доступа не имеют отношения к аутентификации. Права доступа - это из области авторизации.
А вот Вы, похоже, занимаетесь - когда приписываете мне утверждение, которое я не делал. Имею в виду Вашу фразу, что якобы я утверждал нечто подобное:
А я нигде не утверждал про эти Ваши ЛИЧНЫЕ ДАННЫЕ.
Сценарии
Приложения веб-сервера
...
Установленные приложения
...
Клиентские (JavaScript) приложения
...
Приложения на устройствах с ограниченным вводом
...
Сервисные аккаунты
В сценарии авторизации "Сервисные аккаунты"
В этих ситуациях ваше приложение должно подтвердить свою личность для API, но согласие пользователя не требуется.
...
Ваше приложение вызывает API Google от имени учетной записи службы, и согласие пользователя не требуется.
...
Короче инструкция утверждает, что сценарий "Сервисные аккаунты" - это сценарий OAuth 2.0 АВТОРИЗАЦИИ, при которой НЕ ТРЕБУЕТСЯ СОГЛАСИЕ ПОЛЬЗОВАТЕЛЯ.
Поясню. Прямой ответ на вопрос (12) pawlick-а настолько банален, насколько примитивен сам вопрос о супер-пупер-доступе. Дабы направить беседу в русло познания, я написал, будто ошибся в употреблении терминов. Собеседник, начав с пренебрежения терминами "неважнокак*фикации", постепенно пришел к пониманию, что оспаривал мой тезис а-ля "вода мокрая" или "масло масляное". Но суть познавательно-скорректированного тезиса и его аналогичность "маслу масляному" видна только владеющему терминологией. К сожалению, в терминологии pawlick окончательно не разобрался - в отличие от Вас, в итоге он опрометчиво согласился, что мое утверждение (3) ошибочно.
Да ну?! Да неужели?! И в какой момент Вам стало это "очевидно", коллега, не подскажете?
Мы то тут все с утра думали что:
штудируем формулировки Gogle Api, что бы, значить, "правильно мысли формулировать"...
Вот и понятие "согласие" на википедИи прочли: "Согласие - это положительный ответ на предложение, запрос, утверждение".
Но вы тут используете термин "поуправлять правами", так что не волнуйтесь, буквоеды сего мира спят спокойно:
"поуправлять правами" это же одно и тоже что "дать согласие" предоставить на доступ к своим данным.
Двуногая авторизация сервис-аккаунта действительно происходит без участия пользователя, написано в инструкции и проверено на практике. К своему календарю или своему гугл-диску сервис аккаунт имеет доступ безо всяких "дать согласие" и "поуправлять правами" со стороны какого бы то ни было пользователя - после успешной двуногой авторизации.
Процесс аутентификации не решает вопросы предоставления прав доступа - это по определению термина "аутентификация". За предоставление прав доступа отвечает процесс авторизации. Поэтому, после того как я исправил мою ошибку (аутентификация, а не авторизация сервисного аккаунта) - Ваш вопрос стал неуместен, а дальнейшее повторение Ваших домыслов - превратились в демагогию.
Мораль. Не следует относиться к терминам как к чему-то неважному.
В статье описан процесс получения доступа (авторизации) к данным пользователя, находящемся в аккаунте гугл с помощью трехногой авторизации по протоколу OAuth.
В своем комментарии Вы сказали, что это эту задачу можно решить проще: с помощью двуногой аутентификации, без согласия пользователя.
Если у Вас есть время, в это прекрасное воскресенье, ответьте все таки на вопрос: как Вы собираетесь это сделать. Желательно пошагово. Если нет сегодня - ответьте когда будет удобно. Но ответить надо обязательно.
Ну на всякий случай, вдруг одумаетесь. Инструкция по двуногой аутентификации:
краткое описание с картинкой -
подробное -
Я не собираюсь это делать, я это сделал пару лет назад - по приведенной выше инструкции гугла. Никаких подтверждений пользователя в процессе аутентификации не понадобилось - проверенный факт.
Морали мне читать вздумали?! Чудненько...
Ну что, начнем?
Да, мы спорим. И суть нашего спора в следующем: я утверждаю, что Вы не сможете получить доступ к данным пользователя через Google API без его явного согласия пользователя, а Вы утверждаете обратное.
Обозначайте. Вас об этом уже ДВА раза просили: *Apokal1985 в (10) и я в (14). Пока без результатов.
Это Ваша главная ошибка. Вы о них не говорили, потому, что не понимаете что это такое.
Все потому, что 2018 году Вы написали статью , где открыли доступ СВОЕЙ СОБСТВЕННОЙ сервисной учетной записи к СВОЕЙ СОБСТВЕННОЙ 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?
Потом вернитесь к моему изначальному утверждению (3) с учетом поправки (13), на которое был Ваш первый вопрос. Хотя, проще будет повторить мое утверждение в новой редакции.
Мораль: термины надо знать ! Иначе сядешь в лужу )))
Ваши слова?:
Повторяю:
Предоставьте пример получения доступа к данным пользователя без его участия, или и дальше будете выкручиваться?
Ваши слова?:
Повторяю:
Перестаньте выкручиваться, и предоставьте пример получения доступа к данным пользователя без его участия с помощью двуного АУТЕНТИФИКАЦИИ без участия пользователя.
Либо дайте опровержение своих слов.
Учитывая методы ведения Вами диалога, мне, видимо, придется сформулировать свой вопрос так, что бы у Вас не осталось возможностей ответить мне определением «Авторизации» из википедии…
И так:
В статье описывается пример получения доступа сторонним Приложением к событиям календаря пользователя из учетной записи Google по протоколу Oauth. В статье сказано, что для этого Приложению необходимо перенаправить пользователя на сервер авторизации Google, где пользователя явно предоставляет право Приложения на доступ к своим данным, после чего Приложение получает токен.
В своем комментарии под статьей под №3 Вы высказали утверждение, из которого следует, что Вам известна более простая («двуногая») процедура получения Приложением , при которой «подтверждение пользователя совсем не нужно запрашивать».
В комментарии №16 Вы еще раз подтвердили, что знаете, как с помощью «сервисного аккаунта» провести процедуру, описанную в статье, при которой «подтверждений никакого пользователя не требуется».
Приведите пример проведения этой процедуры!
Достаточно пошагового описания процесса, без скриншотов.
В (3) я заметил, что есть вариант аутентификации, когда действий поменьше. Употребив неверный термин "авторизация" - возможно, кого-то я ввел в заблуждение. В (13) я исправил свою ошибку, но Вам это не помогло, увы. Все повторяете и повторяете свой неуместный вопрос.
В статье, которую Вы "экспертно" комментируете, решается совершенно конкретная прикладная задача: получение в 1С событий календаря из учетной записи Google некоего человека с помощью авторизации по протоколу OAuth.
Название статьи "Аутентификация на внешних сервисах посредством OAuth", хотя на самом деле в ней описан процесс "Авторизации".
В первом комментарии сказано
Ваш ответ:
И вопрос тут не в терминологии "Аутентификации" и "Авторизации", Ключевое слово тут "для получения доступа к данными" "подтверждение пользователя совсем не нужно запрашивать". Вы ошибаетесь. Но это не главное. Мы все ошибаемся время от времени.
Если бы Вы сразу признали свою ошибку, все бы закончилось два дня назад.
А Вы вместо признания совей ошибки мечетесь между формулировками, которые к сути спора не относятся.
Но больше всего меня возмущает Ваш поучительный тон и тот факт, что, для сохранения лица Вы обвиняете в невежестве меня, хотя это именно Вы не поняли сути формулировок протокола, и изобрели велосипед с двуногой авторизацией, там где ПО ДУХУ ПРОТОКОЛА должна была быть применена треногая.
Просто признайте свою ошибку. И Все.
*Вернее сделал, но сразу исправил, как только Вы (12) спросили.
Да что Вы заладили.
Вы своей статье получали "access token" для Аутентификации своего приложения, а человек в статье получает access token для авторизации. Ваша статья и эта про совершенно разные процедуры.
И эта статья про АВТОРИЗАЦИЮ, которую ВЫ НИКОГДА не получите без согласия пользователя.
Мне не нравиться демагогия. Но еще больше мне не нравится типы, которые зубрят протоколы не понимая из истинного смысла, а потом швыряются умными фразами, и обвиняют других.
Я от Вас не отстану: либо подтверждайте мою правоту, либо отвечайте на (41)
Это потому, что Вы и Автора статьи ввели в заблуждение своими безграмотным манипулированием терминологий.
Вот поэтому мой вопрос в 41 остается в силе.
А когда Вы не сможете получить доступа к данным пользователя без его согласия (а Вы не сможете) - вот тогда и посмотрим что думает Автор.
Уверен, что календарь автор использовал для проверки результата аутентификации и авторизации, поскольку даже не вынес слово "календарь" в заголовок.
Тех самых данных, которые Вы своим велосипедом из из глупым комментарием (3) без согласия пользователя не получите никогда.
У нас разные заголовки статьи? У меня такой: "Аутентификация на внешних сервисах посредством OAuth"
Я и не собирался получать данные без согласия пользователя. Без согласия пользователя я аутентифицировал сервисную учетку.
Как Вы все-таки невнимательны!
Я в отличие от Вас читаю статьи дальше заголовков.
"Пример подключения к сервисам Google из 1С с помощью протокола OAuth и получения данных с внешнего сервиса."
И access token который получали Вы для аутентификации своей статье и access token который получает тут Автор для авторизации - для одной и тоже цели - получение данных с внешнего сервиса. Тех самых данных, которые Вы своим велосипедом из 805071 из глупым комментарием (3) без согласия пользователя не получите никогда.
Все, что я утверждал - сервисная учетка аутентифицируется без участия пользователя.
Или у Вас уже сомнения, что сервисная учетка аутентифицируется без участия пользователя?
Нужно различать цель получения access token и цель написания статьи. Как житейский пример, цель приобретения инструмента - создание изделий. Но цель магазина инструментов - обеспечение людей инструментами. В магазине инструментов крутятся ролики - как круто работает инструмент. Тем не менее цель магазина инструментов - отнюдь не конечное использование инструмента.
Аналогично, цель данной статьи я вижу именно как инструкцию по "добыче" инструмента (получение access token), а в качестве примера - что этим инструментом можно сделать (поработать с календарем)
Дак я Вам о том и пытаюсь сказать. Вы хотели добиться в своей статье? Токен получить, или данные из своей таблицы? Правильно - данные. Вот и Автор в статье получает токен не ради токена, а ради получения данных.
Т.е access token - это средство для достижения цели: получения данных.
Вы оба добились цели - с помощью токена получи данные.Только сделали это разными способами - Вы получили и Аутентификационный токен, а автор Авторизационный.
Вы оба сделали две фундаментальные вещи:
указали апи API, какое именно приложение к ним обращается (аутентифицировали приложения), и указали API их полномочия (авторизовали приложения).
Только Автор сделал это по классической схеме OAuth, а Вы через одно место.
Именно поэтому Ваш совет из 3 никак не поможет Автору получить access token, потому что он не аутентифицирует приложение а авторизует его. Ему не нужен access token для аутентификации, он уже это сделал указав client_id и client_secret.
Вы еще не до конца разобрались с аутентификацией и авторизацией. Ваше утверждение, что треногий access token не аутентифицирует приложение - ошибочно.
Access token из треногой - и аутентифицирует приложение и авторизует его на доступ к календарю.
Мой совет позволяет получить доступ к календарю альтернативным методом. В совете отсутствует, что нужно сделать для расшаривания календаря под сервисную учетку. Но расшаривание настолько тривиально, что не нужно быть программистом. Когда не пишешь тривиальности - то оставляешь возможность для других чуть-чуть пошевелить мозгами )
Вот и попробуйте их получить с помощью "двуногого" сценария. А там посмотрим..
Похоже, к Вам приходит понимание, что аутентификация - это не авторизация. Еще не до конца, но прогресс налицо. Надеюсь, теперь мы с Вами не будем путать эти термины )
Как назвать - это важно, поскольку в этих разных терминах - разная суть.
А вот эта фраза подсказывает, что Вы не полностью самостоятельно, используя лишь инструкции от гугла, реализовали получение access token. Подглядывали на готовый велосипед? Видимо, поэтому Вам сложно понять, что получение access token - штука не элементарная, и является главной темой обсуждаемой статьи.
Так что, Вы все-таки тоже велосипед изобретали, читая инструкцию гугла про трехногую авторизацию и перекладывая ее на язык 1С? Она там рядышком с двуногой лежит, инструкция-то. Или таки воспользовались уже изобретенным велосипедом типа этой статьи?
Про велосипед Вы не ответили. Сами делали чисто по гугл-документации, или на труды других программистов поглядывали?
Покажите, пожалуйста, где Вы это прочли. Только не поленитесь вместо очередной отсылки типа показать мне конкретное место в тексте, которые подтверждают Ваши слова.
Пустословие - это когда Вы заспамили тему Вашей демагогией, сами что-то придумываете, сами с собой спорите, сами себя опровергаете, многословно объясняете банальности, вместо того, чтобы заняться самообразованием.
Обратите внимание на ошибки, которые Вы допустили из-за непонимания терминологии.То Вам не важно авторизация или аутентификация, то трехногий access token не производит аутентификации, то я утверждаю, что могу получить доступ к данным пользователя без его согласия. Все мимо, все пустое.
Ответьте на вопрос, у Вас проблемы с памятью или с вниманием? Свою ошибку я признал сразу же (13):
Или у Вас проблемы с признанием Ваших собственных ошибок? Не поняли суть моей поправки? Так и признайте, на этом и завершим.
Факт остается фактом:
Сервисная учетка аутентифицируется без подтверждения пользователя.
Сервисная учетка умеет работать с календарями разных пользователей.
При этом secretkey.json используется один на всех пользователей - что довольно удобно.
Отвечаю: нет. Проблем с памятью у мен нет. Иногда с вниманием бывают, но не в этот раз.
Вы признали свою ошибку? Какую именно? С подменой терминов? Да. Признали.
Вы ошиблись не в терминологии. Вы ошиблись с пониманием того, что о чем на самом деле статья. Вы ошиблись в том, что Автор показывает процесс получения токена не для аутентификации, а для авторизации. И Ваше (3) тут совершенно не уместно.
Как видите, я стараюсь отвечать на Ваши вопросы. Ответьте, пожалуйста на мой вопрос в 97
Понимание о чем статья у нас с Вами разные. Каждый концентрирует внимание на то, что ему важно - о том для него и статья.
Мне не интересен календарь, но любопытен процесс добывания токенов доступа - для меня статья об этом.
нужно согласие пользователя.
Получите ли Вы своим "методом" данные календаря? Скорее всего получите, просто с силу того, что к календарям применимо свойство "опубликовать", как и к таблицам.
Но Вы не получите доступа к почте, и вообще ко всему, что не имеет этого "свойства".
То, что Вы изобрели "нетривиальный" способ получения доступа к Google API? Ну это предмет терминологии. Я это назвал "велосипедом", Вы "нетривиальным". Сути эт не меняет. Важно то, что это смесь двух сценариев применения применения протокола. Треногаий сценарий применяется там, где приложению нужен доступ к пользовательским (чужим) данным, двуногий - когда приложению нужен доступ к своим собственным.
Вы их скрестили. Вот поэтому я и называю это "ноу хау".
Все, что Вы передаете в запросе например списка календарей - это акцесс токен, он аутентифицирует Ваше приложение, затем авторизует права доступа этого приложения.
Это коллега, называется "косвенные доказательства".
Факты же говорят о том, однозначно существует связь между Приложением и полученными им токенами,что и позволяет Вам наблюдать картину описанную в 109 (это факт №1).
Но вот что это за связь - бабушка "на двое" сказала.
Может Google API хранит информацию от том, какому приложению какие токены оно выдало, может идентификатор приложения "вшит" в получаемые им токены - это не Вы, не я утверждать не сможем, потому что явного описания этому в протоколе от Google нет (я специально вчера прочел, и для уверенности попросил это сделать Вас).
Но зато можно однозначно утверждать, что на самом первом шаге выполнения варианта протокола, описанного в статье, пользователь направляется на сервер Авторизации, куда вместе с пользователем отправляется "client_id", и именно ЭТО действие позволяет Google API впервые и однозначно идентифицировать приложение. Это, коллега, Факт №2.
Теперь, внимание, вопрос:
Вы согласны с приведенными мною фактами?
Ответьте пожалуйста на него.
Неважно, хранит гугл какому приложению выдан акцесс токен, или вшито это в акцесс токен - в любом случае по акцесс токену определяется приложение. Определение приложения - это и есть процесс аутентификации.
Полностью согласен.
Теперь следите за мыслью:
факты из 111 в совокупности с текстом статьи означают что, в статье, все таки, описан процесс Авторизации приложения, т.е. перенаправление пользователя в Google, для получения от него разрешения на действия с ЕГО данными.
Аутентификация же происходит "фоном", это один из параметров запроса для получения Авторизации, без которого Авторизацию невозможно получить. И это не цель, а СРЕДСТВО получения Авторизации.
Теперь вопрос:
Вы согласны ли Вы, что целью статьи является Авторизация приложения на доступ к данным, в процессе которой происходит неизбежная Аутентификация приложения?
А вот с этого момента, коллега, мы можем "подводить итоги", как Вы вчера выразились, поскольку коллекционирование токенов ради Вашего спортивного интереса - выходит за рамки моего интереса чтения Вашей демагогии.
Когда Вы хотите кушать - Вы добываете пищу, не "для добывания пиши", а для того, что бы утолить голод.
Вот и Автор (и Вы, кстати, тоже в своей статье) получает токен не ради токена, а использует полученный токен для получения данных от Google API. Иначе бы статья Автора закончилась на получении токена.
Таким образом:
а) В статье описан процесс Авторизации приложения (получения согласия пользователя на доступ Приложения к его данным в Google API, подтверждаемого получением Приложением Токена доступа) а не Аутентификации (идентификации приложения в Google API);
б) Авторизацию как в "треногой" так и в "двуногой" схеме протокола OAuth невозможно получить без получения согласия пользователя (да же у Вас в Вашей не получилось, о чем я Вам указал в 31).
б) Процесс Аутентификации приложения в принципе не требует согласия пользоваться по определению.
Таким образом Ваш "лучший" комментарий в (3), ДО вашей корректировки - просто ошибочен, а ПОСЛЕ Вашей корректировки вообще потерял логический смысл и превратился, набор слов, употребленных в одном предложении, где каждое слово по отдельности имеет смысл, но вместе - это "советы космического масштаба и космической же глупости".
Что и требовалось доказать. Честь имею.
Сформулирую для особо одаренных, на всякий случай. Вдруг еще какой демагог прибежит.
Задумайтесь на будущее - кому и какую пользу Вы приносите своим пустословием.
И все-таки долго до Вас доходило. Как видите - Вы оспаривали то, что масло масленое.
Теперь Вам понятно, насколько нелепы были Ваши многословные посты в ответ на такую банальность?
И как смешно смотрелось, когда Вы задавали мне вопрос - нужно ли согласие пользователя на доступ к его данным, требуя от меня ответ на этот риторический вопрос )))
Это все из-за Вашей страсти к демагогии, поработайте над этим тоже.
Если хотите дальше продвигаться в познании двуногой - то на самом деле мой комментарий (3) не ошибочен. Про ошибочность я упростил, чтобы Вам было понятнее. У Вас и так ушло несколько дней для осознания, что масло масляное.
Интересует почему (3) не ошибочен ? Спрашивайте, отвечу. Думаю, приобретенные знания отличия аутентификации от авторизации Вам уже позволят это понять.
Это Ваше утверждение тоже ошибочно. На днях телеграм разблокировали - там при аутентификации клиентского приложения требуется подтверждение пользователя - пользователь должен ввести код из СМС или код из клиента, работающего на другом устройстве.
Соответственно Ваши дальнейшие выводы ошибочны, профессор-недоучка )
В утверждении выше - логическая ошибка. Не требует - не значит запрещает. Аутентификация может быть без подтверждения пользователя, а может быть и с подтверждением - ни то ни другое не противоречит определению "Аутентификация". Отсюда следует: уточнение - требует ли аутентификация подтверждения пользователя или не требует - не лишено смысла.
В этом утверждении тоже ошибка. Процессу Авторизации предшествует процесс Аутентификации. В статье описаны оба процесса - и Аутентификация и Авторизация. Аутентификация производится по client_id + client_secret, авторизация - по подтверждению пользователя с получением code.
И наконец, в этом утверждении опять ошибка. В процессе двуногой авторизации (2LO) - приложение получает access_token после авторизации без согласия пользователя. В 2LO не проверяется право приложения на доступ к объектам пользователя. Пока проверяется только право доступа к необходимым API-scope. Приложение будет аутентифицировано по цифровой подписи - как приложение конкретного проекта, но в случае, если этот проект не подписан на запрашиваемые в scope API - процесс авторизации выдаст отказ приложению в доступе к запрашиваемым scope, при этом access_token не будет получен.
Это не я утверждаю обратное. Это Вы, в виду непонимания термина Аутентификация решили, что я утверждаю обратное. Приписали мне некое суждение, повторяете это выдуманное суждение, опровергаете - классическая демагогия с подменой тезиса.
Вы разницу понимаете между "как правило" и "всегда" ? Или для Вас это так же сложно, как разница между авторизацией и аутентификацией? Неуместные вопросы, неграмотные предположения, нелепые аргументы ... ох и демагог.
Зачем Вы мне это пишете, у меня нет проблем с памятью. Именно поэтому я сразу исправил мою ошибку, заменив авторизацию на аутентификацию. Теперь истинность тезиса неоспорима: "аутентификация сервисной учетки происходит без подтверждения пользователя."
Использовал для доступа к accounts.zoho.com
Долго тупил по поводу ошибки 301 на получении Refresh токена, только потом скопировал 1:1 и понял, что стучался на HTTP, а не на HTTPS.
Спасибо.
и ещё одно замечание до изменения строки кода
ОткрытьФорму("ВнешняяОбработка.АутентификацияGoogle.Форма.ФормаАутентификации", ПараметрыФормы, Элементы.Авторизоваться, ,,,ОО, РежимОткрытияОкнаФормы.БлокироватьОкноВладельца);на
ОткрытьФорму("ВнешняяОбработка.АутентификацияGoogle.Форма.ФормаАутентификации", ПараметрыФормы, Элементы.Авторизоваться, ,,,ОО, );происходила запись дамка и 1с-ка выключалась, платформа 8.3.15.1778
Рейтинг: 181
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 1030500
Создание 03.04.19 09:23
Обновление 03.04.19 09:23
Просмотры 53841
Загрузки 101
Рейтинг
111
Комментарии 134
Код открыт Да
Рубрики Информационная безопасность Внешние источники данных
Кому Разработчик
Тип файла Внешняя обработка (ert,epf)
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Windows
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
