Как из 1с авторизоваться на сайте

Обновлено: 06.07.2024

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

Но как правило, наряду с заведением пользователей в конфигураторе имеет смысл сделать в конфигурации справочник "Пользователи", в котором хранить пользователей, соответствующих пользователям в конфигураторе.
Это дает возможность некоторых вещей, например привязки к пользователю некоторых прав, которыми нельзя управлять с помощью метаданного "Роль", построение системы ограничения прав RLS, привязанной к текущему пользователю, сохранение в справочниках и документах информации об авторах объектов, индивидуальные особенности интерфейса, настроек отчетов, событий и т. д.

Итак. Для выполнения этой задачи в конфигурации требуется сделать нижеперечисленные настройки.

Добавляем в конфигурацию план обмена "РаспределенныеБазы".

Добавляем в конфигурацию иерархический справочник "Пользователи", подчиненный плану обмена "РаспределенныеБазы".

Добавляем в конфигурацию параметр сеанса "ТекущийПользователь" типа "СправочникСсылка.Пользователи".

Добавляем в конфигурацию параметр сеанса "ТекущийУзелРаспределеннойБазы" типа "ПланОбменаСсылка.РаспределенныеБазы".

Добавляем в конфигурацию константу "ЗапретитьЗапускПрограммыНовымПользователям" типа "Булево".

В модуль приложения в процедуру ПередНачаломРаботыСистемы() вставляем код

В модуль внешнего соединения в процедуру ПриНачалеРаботыСистемы() вставляем код

В модуль сеанса, в котором фирма "1С" рекомендует устанавливать параметры сеанса, в процедуру УстановкаПараметровСеанса() вставляем код

Туда же (в модуль сеанса) вставляем процедуру глУстановитьПараметрСеансаТекущийПользователь() и функцию глЕстьДействующиеПользователи()

Собственно все. Теперь программа не запустится, если список пользователей в конфигураторе пустой.

И напоследок немного по логике работы.

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

Константа "ЗапретитьЗапускПрограммыНовымПользователям" создана для того, чтобы при необходимости запретить автоматически программно создавать новых пользователей в справочнике "Пользователи". Может пригодиться в принципе кому-нибудь.

В модуле внешнего соединения проверка авторизованности пользователя выполняется в процедуре ПриНачалеРаботыСистемы(), а не в процедуре ПередНачаломРаботыСистемы() потому, что в модуле внешнего соединения нет события ПередНачаломРаботыСистемы().
Именно поэтому отказаться от запуска программы уже нельзя, но. нужно, поэтому вызываем исключение с заданным текстом ошибки.

Началось все с вопроса "А можно ли сделать так чтобы любой желающий мог получить доступ к нашему веб-клиенту, и для этого не нужно было бы всех заводить руками?". А дальше начались поиски решения) Задача стояла весьма увлекательная. Я, как человек мельком знакомый с веб-разработкой, и по основному профилю специализирующийся на разработке в 1С, видел свет в конце туннеля, но короткого пути не знал) Для решения моей задачи я обратился в интернет. Результатом поисков, проб и ошибок, стало такое решение.

Тестировалось все на
1. 1С 8.3.8 и 1С 8.3.13, но думаю будет работать и на других релизах 8.3

1. Универсальная форма для входа и регистрации в базе 1С. При логине пользователь не видит стандартного окна аутентификации 1С

3. Восстановление пароля пользователя 1С из веб-формы

4. При регистрации и восстановлении пароля пользователь получает письма с паролями

Для тех кому интересны мытарства с разворачиванием веб-сервера и публикацией, смотрим под кат

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

После этого по экрану побегут строки, для нас главное увидеть, что везде написано Success и не написано Error. Как правило установка сервиса проходит успешно, и ошибки в основном происходят в момент ее тестового запуска. Если увидели ошибки, то как правило все они хорошо гуглятся и быстро решаются.

После того как установка прошла успешно желательно зайти в папку Apache\bin в проводнике и запустить ApacheMonitor. Для того чтобы в трее появился интерфейс быстрого управления службой Apache.

Для того чтобы потом удалить Apache нужно тоже зайти в консоль, выполнить то же самое. но с ключом -k uninstall

8. После установки Apache нужно установить модуль расширения web-сервера 1С. Для этого зайдите в список установленных приложений, выберите 1С, и нажмите "Изменить", после в диалоге установки выберите в списке прочего "Модуль расширения web-сервиса"

9. Установка окружения завершена. Остался только сам процесс публикации, который выполняется в пару кликов. Описывать не буду, надеюсь рядовой одинесник без труда с этим разберется. на этом все.

Архитектура решения такова:

Нам остается только подставить правильный адрес в атрибут action нашей формы. И готово.

С остальными функциями веб-формы логина все не так просто.

Хочется переделать на CURL для расширенной работы с ответом веб-сервиса, и переделать вызовы на AJAX. Но пока так.

3. Следующим по очереди идет файл config.php в папке assets, в нем указаны конфигурационные данные для подключения к нашему веб-сервису. код прост и незатейлив. Но сильно упрощает подключение.

из этого файла выбираются параметры для всех операций

4. и style.css, но это не так интересно. Стили здесь не главное.

Дальше переходим к стороне 1С.

/register и /resetPassword

Оба шаблона содержат POST-методы и устроены однообразно

Листинг функции регистрации в упрощенном виде выглядит так

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

Для тех кто станет это скачивать и пробовать. Нужно сделать следующее

1. .Заполнить параметры подключения к почтовому серверу в процедуре ПочтовыйПрофиль(), тогда почта начнет отправляться.

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

Способ применим для случаев, когда веб-сервис и html-страница опубликованы на одном сервере. В этом случае не возникает кросс-доменных проблем. Например, если домены будут отличаться, то Chrome выдаст ошибку:

Failed to load resource: Origin localhost:3299 is not allowed by Access-Control-Allow-Origin

Не вдаваясь в подробности публикации веб-сервисов, предположим, что на стороне 1С создан и опубликован веб-сервис catalogs с операцией Execute. На входе — параметр script типа string, на выходе тип string. Операция запускает на стороне произвольный код script из параметра и возвращает JSON-сериализацию от переменной result.

С JSON-сериализацией удобно работать средствами JavaScript и преобразовать строку в объект/массив одной командой eval(resultText). В Интернете можно найти несколько JSON-сериализаторов для 1С.

Удостоверимся, что веб-сервис отвечает, введя его адрес:

На форме сверху разместим элементы настройки веб-сервера: wsUrl — адрес веб-сервиса, wsUser — логин, wsPassword — пароль. На стороне веб-сервиса 1С включена basic autherization. Логин и пароль соответствуют пользователю, прописанному в 1С.

Левая панель отвечает за отображение доступных справочников catalogsList, правая — за отображение букв (letters) и данных (catalogRecords).

JavaScript

Функция обращения к SOAP веб-сервису определена следующим образом:

Получение списка наименований каталогов.

Получение первых букв наименований справочника

Получение данных для каталога , где первая буква входит в условие .

При нажатии на кнопку Обновить происходит вызов функции

и при успешном выполнении вызывается обработчик processSuccess

Веб-сервис возвращает xml, где значимым является содержимое m:return-тэга — JSON-сериализация. Перевести его в объекты JavaScript можно через eval-вызов. Обработчик очищает перечень справочников и заново его формирует через li-тэги с атрибутом catalog. Каждому элементу устанавливается класс catalogTitle.

Аналогично обрабатываются нажатия на все управляющие элементы. Нажатие на справочник очищает буквы и данные, перезаполняет буквы. Нажатие на букву перезаполняет данные из справочника. За обработку кода на 1С отвечают куски кода в script-блоках с типом «text/1c».
Приложение выглядит так:

Нерешенная проблема авторизации на браузере IE

Существует проблема авторизации на IE. На IE 8/9 не удалось решить проблему basic authorization аналогичным для остальных браузеров методом.

На IE Ajax не работает с использованием user/password — свойств $.ajax. На FF и Chrome все работает нормально. По какой-то причине на сервер в случае с IE не передается заголовок

Authorization: Basic 0JHQsNGF0YjQuNC10LLQn9CYICjRgNGD0LrQvtCy0L7QtNC40YLQtdC70YwpOg==
Если кто-нибудь знает причину и как обойти, пожалуйста, напишите в комментариях.

Выводы

Предложенный подход на основе SOAP имеет право на существование для несложных задач, так как сопровождается достаточно большим числом JavaScript кода. Возможно, в будущем удастся создать JavaScript фреймворк для упрощения процесса создания приложений.

Разработчики в этом способе самостоятельно отвечают за безопасность. Необходимо проверять входные параметры при записи, не позволять запуск произвольных скриптов, переданных с клиента. В статье выполнение произвольного кода показано только для примера. Унифицировать можно выполнение произвольного запроса, но это связано с опасностью SQL-инъекций.

Внешние компоненты Native API от 1С не будут работать в данной среде. Это значит, что нужно дополнительно решать проблему с написанием драйверов для оборудования.

Провайдер аутентификации облачного сервиса Фреш позволяет войти в приложение пользователя из стороннего сервиса без использования дополнительной аутентификации и авторизации.

Этот способ аутентификации предназначен для организации "прозрачного" входа по технологии единого входа ( Single Sign-On ) , когда пользователь уже работает в своем личном кабинете в стороннем (по отношению к сервису Фреш) сервисе.

Организация единого входа возможна 2-мя способами:

Если сторонний сервис поддерживает технологию OAuth2 или OpenID-Connect, то на стороне сервиса Фреш нужно выполнить настройки в соответствии с данными провайдера стороннего сервиса.
Если сторонний сервис не поддерживает технологию OAuth2 или OpenID-Connect, то на стороне этого сервиса должна быть выполнена разработка для обеспечения поддержки прозрачной аутентификации.

Настройка сервиса Фреш для "прозрачного" входа из сервисов, поддерживающих OAuth2 и OpenID-Connect описана в главе "Использование сторонних провайдеров аутентификации" документа "1С:Облачная подсистема Фреш".

Схема работы с использованием OAuth2 или OpenId-Connect

Также поддерживаются некоторые отступления от стандарта, чтобы реализовать возможность авторизации через провайдеры, которые реализуют только OAuth2 и не используют стандарт OpenID-Connect целиком. Подробнее см. главу документации Продвинутые настройки взаимодействия с провайдером аутентификации.

Подключение приложения

Для подключения в стороннем провайдере необходимо установить идентификаторы приложения Фреш:

Точки взаимодействия

Получение ключа доступа

Идентификатор приложения Фреш

Адрес, на который будет переадресован пользователь после прохождения авторизации. Должен совпадать с redirect_uri, указанным на этапе подключения приложения Фреш

Набор разрешений, запрашиваемых приложением Фреш у провайдера, бывает не обязателен для определенных провайдеров.

Тип ответа, который необходимо получить. Фреш использует параметр code.

Любое значение, которое провайдер вернет на redirect_uri. Фреш использует JWT-токен для передачи значений возврата.

2. Разрешение прав доступа. Если пользователь не авторизован, ему будет показана форма входа провайдера. После успешного входа пользователю будет предложено авторизовать приложение, разрешив доступ к своим данным.

Защищенный ключ приложения

Адрес, на который будет переадресован пользователь после прохождения авторизации. Должен совпадать с redirect_uri, указанным на этапе подключения приложения

Код, полученный после прохождения авторизации

Тип запрашиваемого ресурса. Значение равно "authorization_code".

В результате выполнения запроса приложение Фреш ожидает получить JSON c ключами, например:

Поле access_token в общем случае обязательно, но может быть передано и в данных при возврате на запрос разрешения прав доступа (шаг 2).

Получение данных пользователя

В результате выполнения запроса приложение Фреш ожидает получить данные пользователя в ответе в виде JSON, например:

Обрабатываемые свойства, которые ожидает получить приложение Фреш:

Свойство	Обязательное	Описание
sub	Да	Идентификатор пользователя с стороннем сервисе для сопоставления пользователя в приложении Фреш
email	Да	Адрес электронной почты пользователя. Используется в сервисе Фреш для поиска уже существующих пользователей. В рамках сервиса не может быть указано 2х одинаковых email.
phone		Номер телефона
first_name		Имя
last_name		Фамилия
middle_name		Отчество
public_id		Публичный идентификатор пользователя, например ИНН.

Имена свойств могут отличаться. Взаимодействие с провайдером в приложении Фреш настраивается для каждого провайдера индивидуально.

Схема работы без использования OAuth2 и OpenId-Connect

Схема работы, которую должен поддержать сервис, не поддерживающий OAuth2 или OpenID-Connect

Процесс входа пользователя в приложение облачного сервиса Фреш по технологии единого входа без использования OAuth2 или OpenID-Connect:

Обслуживающая организация перенаправляет пользователя на адрес OpenID-провайдера методом POST. В теле запроса содержатся данные аутентификации, адрес приложения, одноразовый ключ (вместо пароля).
Данные верифицируются OpenId-провайдером с помощью симметричной подписи без обращению к провайдеру.
Устанавливает cookie одноразового входа.
OpenID-провайдер перенаправляет пользователя на адрес приложения.
Приложение перенаправляет пользователя на OpenID-провайдер и передает OpenID-провайдеру ранее установленную им cookie (это стандартная схема работы с OpenID-провайдером).
OpenID-провайдер обнаруживает cookie и перенаправляет пользователя на приложение с разрешением входа.

Получение секретного ключа

Для подписи данных авторизации используется секретный ключ. Секретный ключ генерируется OpenID-провайдером облачного сервиса Фреш.

Возможны 2 варианта автоматизированного получения секретного ключа:

Периодическая отправка ключа, инициируемая облачным сервисом Фреш
Отправка ключа по запросу от обслуживающей организации

На адрес сервиса для передачи ключа приходит запрос с разметкой JSON c данными:

id - идентификатор ключа подписи
expired - срок действия ключа подписи
key - двоичные данные ключа подписи в формате base64

Адрес OpenID провайдера сервериса

Одноразовый номер для защиты от атак повторного использования (дата в формате XML до Z + GUID)

Генерируется обслуживающей организацией при каждом запросе.

Номер области данных пользователя

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

assoc_handle
response_nonce
provider
user_id
user
tenant

Алгоритм вычисления подписи на псевдокоде:

* Для входа можно использовать идентификатор пользователя (user_id) или логин пользователя (user).

Пример страницы для перенаправления пользователя в приложение

Необходимо перенаправлять пользователя на эту HTML страницу в момент нажатия ссылки на вход в приложение.

Читайте также: