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

Публикация № 1030500

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

OAuth

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

 В данной  статье на примере подключения к сервисам 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:

.epf 13,71Kb
01.04.19
27
.epf 1.0 13,71Kb 27 Скачать

Специальные предложения

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

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

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

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

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

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

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

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

andrey.jiivih*gmail.com

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

Где говорил про "ЛИЧНЫЕ ДАННЫЕ ПОЛЬЗОВАТЕЛЯ"? Не фантазируйте )
Я обозначил метод, которым можно провести двуногую аутентификацию сервисной учетки без участия пользователя, не более. Результатом аутентификации будет access token сервисной учетки. Как использовать access token - это другой вопрос.
21. uno-c 161 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 161 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 161 30.05.20 16:26 Сейчас в теме
(24) Моя цель - обозначить альтернативу. Статья называется "Аутентификация на внешних сервисах посредством OAuth". В статье описана трехногая аутентификация. Я заметил, что можно сделать и двухногую аутентификацию. В процессе двухногой аутентификации не требуется рисовать форму браузера, не требуется подтверждение пользователя - действий меньше. Все что нужно для 2LO аутентификации - скачать в дашборде (https://console.developers.google.com/apis/dashboard) secretkey.json, поставить им цифровую подпись, добавить эту подпись в HTTPЗапрос. В итоге access token получаем путем всего одного HTTPЗапроса.
26. uno-c 161 30.05.20 18:16 Сейчас в теме
(22)
Не надо манипулировать понятиями

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

А я нигде не утверждал про эти Ваши ЛИЧНЫЕ ДАННЫЕ.
27. uno-c 161 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 161 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 161 01.06.20 14:24 Сейчас в теме
(31) Вы таки и не удосужились прочитать, чем аутентификация отличается от авторизации. Напрягитесь, это гораздо быстрее, чем писать столь длинные посты )))
Потом вернитесь к моему изначальному утверждению (3) с учетом поправки (13), на которое был Ваш первый вопрос. Хотя, проще будет повторить мое утверждение в новой редакции.

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


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


Повторяю:

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


Повторяю:

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

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

И так:

В статье 1030500 описывается пример получения доступа сторонним Приложением к событиям календаря пользователя из учетной записи Google по протоколу Oauth. В статье сказано, что для этого Приложению необходимо перенаправить пользователя на сервер авторизации Google, где пользователя явно предоставляет право Приложения на доступ к своим данным, после чего Приложение получает токен.
В своем комментарии под статьей под №3 Вы высказали утверждение, из которого следует, что Вам известна более простая («двуногая») процедура получения Приложением , при которой «подтверждение пользователя совсем не нужно запрашивать».
В комментарии №16 Вы еще раз подтвердили, что знаете, как с помощью «сервисного аккаунта» провести процедуру, описанную в статье, при которой «подтверждений никакого пользователя не требуется».
Приведите пример проведения этой процедуры!
Достаточно пошагового описания процесса, без скриншотов.
42. uno-c 161 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 161 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 161 01.06.20 15:49 Сейчас в теме
(46) Статья называется "Аутентификация ...". - про аутентификацию я и писал. Есть еще вопросы?
48. Pawlick 10 01.06.20 15:50 Сейчас в теме
49. uno-c 161 01.06.20 15:57 Сейчас в теме
(48)Ответ:
Поскольку я писал только про аутентификацию сервисной учетки без участия пользователя - вопрос (41) неуместен.
50. Pawlick 10 01.06.20 16:00 Сейчас в теме
(49)
Это Ваш комментарий в 3 неуместен к этой статье
51. uno-c 161 01.06.20 16:02 Сейчас в теме
(50) Автор статьи думает иначе )
Если попробуете с нуля, глядя только в инструкции гугла, получить access token - то Вы согласитесь с автором.
52. Pawlick 10 01.06.20 16:06 Сейчас в теме
(51)
Это потому, что Вы и Автора статьи ввели в заблуждение своими безграмотным манипулированием терминологий.

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

А когда Вы не сможете получить доступа к данным пользователя без его согласия (а Вы не сможете) - вот тогда и посмотрим что думает Автор.
54. uno-c 161 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 161 01.06.20 16:19 Сейчас в теме
(56) Аутентификация сервисной учетки не требует подтверждения пользователя - это мой тезис.
Доступ - это не аутентификация, а авторизация.
58. Pawlick 10 01.06.20 16:21 Сейчас в теме
(57) Главный тезис здесь - получения данных с внешнего сервиса, которые Вы не сможете сделать просто аутентифицировав сервисную учетку.
59. uno-c 161 01.06.20 16:23 Сейчас в теме
(58) Ну это для Вас. Для меня главный тезис - первое слово в заголовке статьи.
60. Pawlick 10 01.06.20 16:24 Сейчас в теме
(59)
Это называется "слышал звон да не знаю где он"
61. uno-c 161 01.06.20 16:24 Сейчас в теме
(60) Это называется - попробуй сам и поймешь, что главное.
62. Pawlick 10 01.06.20 16:27 Сейчас в теме
(61)
У меня работающая служба синхронизации календарей с Google API, и Microsoft Grapf.
Так что давно уже все попробовал...
63. uno-c 161 01.06.20 16:28 Сейчас в теме
64. uno-c 161 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 161 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 161 01.06.20 17:30 Сейчас в теме
(70) Тогда Вы плохо следите за корректностью выражений
для получения данных с внешнего сервиса, что и указано в заголовке статьи.


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

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

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

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

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

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

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


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

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

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

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

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

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

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


Покажите, пожалуйста, где Вы это прочли. Только не поленитесь вместо очередной отсылки типа этой показать мне конкретное место в тексте, которые подтверждают Ваши слова.
103. uno-c 161 02.06.20 14:32 Сейчас в теме
(97) Это нигде не написано. Это нужно понять. Вам объяснить или сами попробуете?
96. uno-c 161 01.06.20 23:32 Сейчас в теме
(94)
вы пустослов, сударь

Пустословие - это когда Вы заспамили тему Вашей демагогией, сами что-то придумываете, сами с собой спорите, сами себя опровергаете, многословно объясняете банальности, вместо того, чтобы заняться самообразованием.
Обратите внимание на ошибки, которые Вы допустили из-за непонимания терминологии.То Вам не важно авторизация или аутентификация, то трехногий access token не производит аутентификации, то я утверждаю, что могу получить доступ к данным пользователя без его согласия. Все мимо, все пустое.
100. uno-c 161 02.06.20 06:17 Сейчас в теме
(44)
Просто признайте свою ошибку. И Все.

Ответьте на вопрос, у Вас проблемы с памятью или с вниманием? Свою ошибку я признал сразу же (13):
Если имеете в виду ошибку употребления терминов - то конечно Вы правы. Не двуногая авторизация, а двуногая аутентификация.


Или у Вас проблемы с признанием Ваших собственных ошибок? Не поняли суть моей поправки? Так и признайте, на этом и завершим.
Факт остается фактом:
Сервисная учетка аутентифицируется без подтверждения пользователя.
Сервисная учетка умеет работать с календарями разных пользователей.
При этом secretkey.json используется один на всех пользователей - что довольно удобно.
102. Pawlick 10 02.06.20 14:30 Сейчас в теме
(100)
Ответьте на вопрос, у Вас проблемы с памятью или с вниманием?


Отвечаю: нет. Проблем с памятью у мен нет. Иногда с вниманием бывают, но не в этот раз.

Вы признали свою ошибку? Какую именно? С подменой терминов? Да. Признали.
Вы ошиблись не в терминологии. Вы ошиблись с пониманием того, что о чем на самом деле статья. Вы ошиблись в том, что Автор показывает процесс получения токена не для аутентификации, а для авторизации. И Ваше (3) тут совершенно не уместно.

Как видите, я стараюсь отвечать на Ваши вопросы. Ответьте, пожалуйста на мой вопрос в 97
104. uno-c 161 02.06.20 14:33 Сейчас в теме
(102) Ошибку я признал сразу. Употребил авторизация вместо аутентификации. Разумеется.
Понимание о чем статья у нас с Вами разные. Каждый концентрирует внимание на то, что ему важно - о том для него и статья.
Мне не интересен календарь, но любопытен процесс добывания токенов доступа - для меня статья об этом.
105. Pawlick 10 02.06.20 14:39 Сейчас в теме
(102)
а для авторизации

нужно согласие пользователя.

Получите ли Вы своим "методом" данные календаря? Скорее всего получите, просто с силу того, что к календарям применимо свойство "опубликовать", как и к таблицам.

Но Вы не получите доступа к почте, и вообще ко всему, что не имеет этого "свойства".

То, что Вы изобрели "нетривиальный" способ получения доступа к Google API? Ну это предмет терминологии. Я это назвал "велосипедом", Вы "нетривиальным". Сути эт не меняет. Важно то, что это смесь двух сценариев применения применения протокола. Треногаий сценарий применяется там, где приложению нужен доступ к пользовательским (чужим) данным, двуногий - когда приложению нужен доступ к своим собственным.
Вы их скрестили. Вот поэтому я и называю это "ноу хау".
Оставьте свое сообщение

См. также

Практический пример настройки обмена с казначейством в БГУ Промо

Внешние источники данных v8 БГУ Россия Госбюджет Абонемент ($m)

Материалов для бюджетников, всегда не хватает, особенно с практическими примерами. Попробую описать процесс настройки с нуля обмена с ОФК/УФК на примере выгрузки документа «Заявки на кассовый расход» из БГУ и импорта в СЭД.

1 стартмани

13.04.2012    66307    Vestr    17    

Ограничение доступа пользователей к внешнему отчёту на СКД

Роли и права v8 v8::Права v8::СКД 1cv8.cf Абонемент ($m)

Метод ограничения доступа пользователей к данным внешнего отчёта.

1 стартмани

04.04.2020    2719    user925427    14    

Права на объект (расширение, отчет)

Роли и права v8 v8::Права 1cv8.cf Абонемент ($m)

Если пользователю не хватает прав на объект, то на практике в 90 % случаев, недостающую роль можно найти через типовой регистр сведений Права ролей. Также с помощью дополнительного отчета или небольшого расширения можно ускорить описанный процесс.

1 стартмани

07.01.2020    18959    sapervodichka    21    

RLS - дубли условий в запросах к СУБД

Практика программирования Роли и права v8 v8::Права 1cv8.cf Абонемент ($m)

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

1 стартмани

07.10.2019    8474    geron4    4    

Вебхук. Путь Телеграма

Внешние источники данных Интеграция v8 Абонемент ($m)

Долгое (на самом деле нет) и нелегкое путешествие телеграма к неведомым (из за РКН) конфигурациям 1С. Памятка себе.

1 стартмани

03.10.2019    17671    platonov.e    26    

Описание формата внутреннего представления данных 1С в контексте обмена данными

Практика программирования Внешние источники данных v8 v8::УФ 1cv8.cf Абонемент ($m)

Фирма 1С не рекомендует использовать внутреннее представление данных для любых целей, которые отличны от обмена с 1С:Предприятием 7.7. Но сама возможность заглянуть на "внутреннюю кухню" платформы с помощью функций ЗначениеВСтрокуВнутр(), ЗначениеВФайл(), ЗначениеИзСтрокиВнутр() и ЗначениеИзФайла(), дала возможность сообществу программистов 1С разработать новые приемы разработки и анализа. Так, именно на использовании внутреннего представления был построен алгоритм "быстрого массива", который позволяет практически мгновенно создать массив в памяти на основании строки с разделителями. С помощью разбора внутреннего представления можно "на лету" программным кодом выполнить анализ обычной формы и даже сделать редактор графической схемы. Во внутреннем формате сохраняют свои данные между сеансами различные популярные внешние обработки. А еще это возможность сделать быстрый обмен с внешними системами.

1 стартмани

06.09.2019    19478    Dementor    30    

Обмен большими данными между клиентом и сервером

Внешние источники данных v8 Абонемент ($m)

В статье рассматривается вопрос передачи больших объемов данных, превышающих теоретический лимит сеансовых данных (4Гб за вызов) (они же временное хранилище) как с клиента на сервер, так и в обратном направлении.

1 стартмани

27.08.2019    13553    logos    24    

АИТП. Простой, событийно-управляемый обмен данными

Внешние источники данных v8 1cv8.cf Абонемент ($m)

В статье, на примере обмена с ЗУП 3.1, демонстрируется механизм событийно-управляемого взаимодействия конфигурации АИТП с прикладными решениями на платформе 1С:Предприятие.

1 стартмани

04.07.2019    4887    blackhole321    0    

Интеграция 1С с Битрикс CRM через REST API

Внешние источники данных v8 1cv8.cf Абонемент ($m)

На фоне неутихающего обострения «бизнеса» по внедрению СРМ-систем остро встают вопросы обмена данными с уже существующими системами. В статье рассматривается выгрузка контактов, товаров и сделок из 1С в Битрикс CRM через REST API, приложена обработка для тестирования.

1 стартмани

28.06.2019    22231    muzipov    9    

1C + Python + Django Rest Framework + Vue.js. Опыт несложной full-stack разработки

Практика программирования Внешние источники данных Обмен через XML WEB Разработка v8 1cv8.cf Абонемент ($m)

В этой статье мы рассмотрим путь и основные моменты создания небольшого вэб-сервиса, который мы называем "Онлайн Прайс-лист". Выгрузка из 1С, бэкенд, фронтенд, получение заказов в 1С.

1 стартмани

22.04.2019    33265    riposte    65    

Телеграм + 1С + Вебхуки + Апач + Самоподписанный сертификат

Внешние источники данных v8 Абонемент ($m)

Много строк исписано про интеграцию Телеграма и 1С. Но нигде не увидел полной инструкции по установке и настройке вебхуков. Попробую её написать.

1 стартмани

26.02.2019    16058    alexlx    30    

Универсальное расширение 1С для Google Таблиц и Документов

Внешние источники данных v8 1cv8.cf Абонемент ($m)

Эта статья для тех, кто использует G Suite и 1С. Готовое решение для выгрузки отчетов и печатных форм из баз 1С в Google Диск в формате Google Таблиц и Google Документов. Информация по его внедрению. Описание создания и настройки проекта в GCP.

1 стартмани

31.01.2019    16412    Maria18    25    

Применение средств MS SQL R service для 1С

Внешние источники данных v8 1cv8.cf Абонемент ($m)

Некоторое время назад Microsoft добавила в MS SQL сервер службы машинного обучения, позволяющие выполнять программный код на языках программирования R и Python. В статье будет продемонстрирована общая схема и принцип того, как можно использовать данные службы в контексте разработки на 1С. 

1 стартмани

25.11.2018    14323    Robbi    14    

Связка 1С и Telegram. Отправка стикеров

Практика программирования Внешние источники данных v8 v8::УФ 1cv8.cf Абонемент ($m)

В качестве факультатива сейчас изучаю возможности связки 1С и мессенджера Telegram. И возник вопрос, как помимо сообщений, посылать в ответ на действия пользователя произвольный стикер? Решению этой мини задачи и посвящена данная статья.

1 стартмани

31.07.2018    12489    Skin123    4    

Опыт интеграции мессенджера Telegram c 1C

Внешние источники данных Интеграция v8 Абонемент ($m)

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

19.07.2018    21701    VachKirp    43    

Опять про sFTP и вообще

Внешние источники данных v8 1cv8.cf Абонемент ($m)

Памятка для разработчика по работе с FTP, FTPs и sFTP.

1 стартмани

23.05.2018    18585    leongl    13    

Использование регулярных выражений (RegExp) в Linux

Сервисные утилиты Администрирование данных 1С Внешние источники данных v8 Абонемент ($m)

Описывается способ использования регулярных выражений (RegExp) в Linux с использованием тех же компонентов, что и в Windows (COM-объекты VBScript.RegExp).

1 стартмани

20.04.2018    8555    vsbronnikov    12    

Лицензия не получена: Ошибка программного лицензирования Error=-2147217394 (0x8004100E)

Администрирование данных 1С Информационная безопасность v8 Абонемент ($m)

Решение проблемы пропавшей лицензии и ошибки при ее восстановлении - "Лицензия не получена: Ошибка программного лицензирования Error=-2147217394 (0x8004100E)".

1 стартмани

06.04.2018    11857    a_titeev    4    

Практикум по созданию обменов данными через протокол oData «за полдня»

Практика программирования Внешние источники данных v8 1cv8.cf Россия Абонемент ($m)

Про oData и 1С было довольно много написано, однако же описания работы и с чтением, и с записью данных через JSON я так и не встретил ни на этом ресурсе ни на других. Попробую раскрыть эту тему.

1 стартмани

20.03.2018    26306    timm00    64    

Защита данных платформы 1С: Предприятие

Информационная безопасность v8 v8::УФ 1cv8.cf Абонемент ($m)

Платформа 1С: Предприятие предоставляет возможности защиты данных и контроля доступа. Является ли это самоуспокоением?

1 стартмани

15.02.2018    9656    Ликреонский    13    

Пример добавления собственных ролей пользователям через расширение 1С

Практика программирования Информационная безопасность v8 v8::Права 1cv8.cf Абонемент ($m)

В публикации представлена пошаговая инструкция создания собственных ролей с использованием расширения 1С:Предприятие 8.3.10 и программа с примером.

1 стартмани

18.01.2018    40937    flyDrag    21    

Практика доступа в базу 1С через протокол oData. Изменение данных

Практика программирования Внешние источники данных v8 1cv8.cf Абонемент ($m)

Продолжаем знакомство с протоколом oData и в данной статье мы рассмотрим такие вопросы, как минимально необходимый багаж теоретических знаний, необходимый для работы, способы изменения доступных данных, а также с какими ограничениями можем при этом столкнуться. Осторожно, будет много скриншотов!

1 стартмани

30.12.2017    34799    Dementor    27    

Инструкция по настройке загрузки из ФСС электронных листков нетрудоспособности ЭЛН в документ 1С Начисление по больничному листу

Внешние источники данных Зарплата Зарплата v8 КА1 ЗУП2.5 УПП1 Россия БУ ФОМС, ПФ, ФСС Абонемент ($m)

Клиент (страхователь) работает в программе "1С Зарплата и управление персоналом ред.2.5" сдает отчетность через Контур или СБИС и не собирается подключать 1С-Отчетность, при этом хочет загружать электронные больничные в программу 1С Зарплата. Подобная ситуация может быть и для других конфигураций в которых есть документ "Начисление по больничному листу", например Комплексная автоматизация 1.1, Управление производственным предприятием 1.3.

1 стартмани

28.11.2017    150590    rusmil    126    

Google OAuth и мобильное приложение

Мобильная разработка Обмен данными 1С Внешние источники данных WEB v8 v8::Mobile 1cv8.cf Абонемент ($m)

Об аутентификации для работы с сервисами google из мобильного или настольного приложения

1 стартмани

29.08.2017    11541    stveans@gmail.com    3    

Опыт интеграции 1С с системой Меркурий (Часть 5)

Внешние источники данных Интеграция Оптовая торговля Оптовая торговля v8::ОУ 1cv8.cf Сельское хозяйство и рыболовство Транспорт, автопарки, такси Оптовая торговля, дистрибуция, логистика Пищевая промышленность Россия БУ УУ Абонемент ($m)

Описывается опыт внедрения в 1С системы работы с ветеринарно-сопроводительными документами Меркурий. Интеграция еще в процессе и приветствуется обмен опытом.

1 стартмани

10.07.2017    59453    axxell    33    

1С и MongoDB: дружба начинается с RESTHeart'а

Внешние источники данных v8 Абонемент ($m)

Краткое описание того, как подружить MongoDB и 1С: Предприятие используя один из предлагаемых на официальном сайте RESTFul сервисов - RESTHeart.

1 стартмани

03.07.2017    43272    Silenser    8    

Что такое HMAC и JWT и как это использовать в 1С

Внешние источники данных v8 1cv8.cf Абонемент ($m)

Лёгкая статья про стандарты HMAC и JWT с небольшой теорией и исходным кодом.

1 стартмани

20.04.2017    21594    keypax    48    

Получение информации об экспортных свойствах и методах объектов 1С через COM.

Разработка внешних компонент Внешние источники данных v8 1cv8.cf Абонемент ($m)

Как из тела COM-объекта или внешней компоненты определить состав свойств и методов объектов 1С агрегатных типов? Все ответы здесь.

1 стартмани

03.09.2013    14251    gislink    5    

Функция получения значения характеристики по ее наименованию

Практика программирования Информационная безопасность v8 1cv8.cf Россия Абонемент ($m)

Полезная функция для получения значения произвольной пользовательской, не предопределенной, характеристики из ПланВидаХарактеристик.НастройкиПользователей

1 стартмани

03.08.2012    7761    Sergeevich    7    

Синхронизация с сервером 1С во внешнем соединении

Внешние источники данных Универсальные функции v8 1cv8.cf Абонемент ($m)

Позволяет установить время удаленного SQL-сервера на компьютере при выполнении обмена через Внешнее соединение

1 стартмани

27.09.2011    13409    sml    6