Как из 1с авторизоваться на сайте
По хорошему при серьезном подходе к автоматизации нужно запрещать неавторизованный вход в программу.
Исключение могут составлять крайне редкие случаи, например, демо-версия конфигурации или конфигурация публичного пользования.
Но как правило, наряду с заведением пользователей в конфигураторе имеет смысл сделать в конфигурации справочник "Пользователи", в котором хранить пользователей, соответствующих пользователям в конфигураторе.
Это дает возможность некоторых вещей, например привязки к пользователю некоторых прав, которыми нельзя управлять с помощью метаданного "Роль", построение системы ограничения прав 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.
Веб-сервис возвращает 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 | Да | Идентификатор пользователя с стороннем сервисе для сопоставления пользователя в приложении Фреш |
| Да | Адрес электронной почты пользователя. Используется в сервисе Фреш для поиска уже существующих пользователей. В рамках сервиса не может быть указано 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 страницу в момент нажатия ссылки на вход в приложение.
Читайте также: