2.3. Аутентификация в HTTP сервисах#

Для всех HTTP-сервисов используется HTTP-аутентификация. В каждый HTTP-запрос клиент должен добавлять аутентификационные данные.

Доступны Basic и Bearer аутентификация.

See also

HTTP сервисы, CoreAuthProvider

2.3.1. Basic#

При Basic-аутентификации, клиент должен передать в запросе:

  • Имя пользователя

  • Пароль

  • Имя базы

Имя пользователя и пароль передаются через HTTP-заголовок:

  • Authorization со значенеим Basic {Base64Cred}

где: {Base64Cred} - строка user:password, кодированная в Base64.

Имя базы может быть передано через (в порядке приоритета):

  • Сегмент строки адреса. Пример: http://server/{DATABASE}/

  • HTTP-загловок Database со значением {DATABASE}

  • HTTP-параметр Database со значением {DATABASE}. Пример: http://server/?Database={DATABASE}

где {DATABASE} - имя базы данных.

Note

Если имя базы не передано ни одним из описанных способов, будет произведена попытка аутентификации с использованием имени базы по-умолчанию. База по умолчанию определяется из конфигурационного файла global3.config.xml (в порядке приоритета).

  • Значение атрибута <databases defaultDb="{alias}"/>

  • Значение атрибута <database alias="DATABASE"/> первой базы в списке конфигураций <databases/>

Проверка учётных данных для Postgres решения выполняется в GTK, вызовом CoreAuthProvider.login().

2.3.2. Bearer#

При Bearer-аутентификации, клиент должен передать в запросе:

Токен аутентификации передаётся через HTTP-заголовок:

  • Authorization со значенеим Bearer {Token}

где: {Token} - строка с токеном аутентификации.

Note

Токен может быть передан альтернативными способами:

  • Через Cookie с именем access_token

  • Через HTTP-параметр с именем access_token

Имя базы может быть передано через (в порядке уменьшения приоритета):

  • Сегмент строки адреса. Пример: http://server/{DATABASE}/

  • HTTP-загловок Database со значением {DATABASE}

  • HTTP-параметр Database со значением {DATABASE}. Пример: http://server/?Database={DATABASE}

где {DATABASE} - имя базы данных.

Note

Если имя базы не передано ни одним из описанных способов, будет произведена попытка аутентификации с использованием имени базы по-умолчанию. База по умолчанию определяется из конфигурационного файла global3.config.xml (в порядке приоритета).

  • Значение атрибута <databases defaultDb="{alias}"/>

  • Значение атрибута <database alias="DATABASE"/> первой базы в списке конфигураций <databases/>

2.3.3. Remote#

Аутентификация пользователя в системе выполняется на прокси-сервере, через который проходят все запросы от пользователей к серверу приложений Global. После успешной аутентификации, прокси сервер должен направить клиента на адрес сервера приложений Global, содержащий имя решения http(s)://server.domain/{SOLUTION}/. В http-запрос должны добавлены заголовки: - X-Remote-User со значением имя_пользователя. - X-Proxy-Token со значением аутентификационный_токен_прокси_сервера.

Сервер приложений, получив http-запрос с указанными выше заголовками, проверяет валидность токена прокси сервера вызовом метода CoreAuthProvider.loginRemote(). Если токен прокси сервера валиден, пользователь, с указанным в заголовке именем, считается аутентифицированным в системе, ему выдаётся пользовательский ast-токен (если он не был выдан ранее) и разрешается работа.

2.3.3.1. Токен#

Токеном аутентификации является строка в формате: {тип}_{тело}.

Где:

  • {тип} - Тип токена.

  • {тело} - Тело токена: хэш или JWT.

2.3.3.1.1. Типы токенов#

Тип токена определяет место валидации и алгоритм обработки содержимого токена.

Note

За сервером приложений зарезервированы имена типов, начинающиеся с символа a.

В текущей версии, сервер приложений формирует токены с типами:

  • ast - Application Server Token

    Токен формируется сервером приложений после входа в приложение Глобал с использованием имени пользователя и пароля. Токен возвращется клиенту в Cookie access_token, привязанной к подмножеству адресов http[s]://server/{DATABASE}/. Эта Cookie автоматически присоединяется ко всем запросам по адресам http[s]://server/{DATABASE}/, выполняемым из браузера, аутентифицированного в системе Глобал.

    Note

    Токены ast устаревают через 48 часов после создания и автоматически обновляются через 12 часов, при работе пользователя с системой.

Валидация токенов других типов выполняется в GTK, вызовом CoreAuthProvider.loginBearer().