Авторизация по логину и паролю

Авторизация по логину и паролю позволяет внешней программе обращаться к API TesLab от имени сотрудника. Программа отправляет учётные данные, получает токен сессии и использует его в последующих запросах. В этой статье показано, как получить token.auth и проверить, под какой учётной записью выполняется обмен.

В этой статье

• Что подготовить
• Параметры входа
• Запрос входа
• Успешный ответ
• Проверка сессии
• Если запрос не выполнен
• Сведения о сотруднике в user
• Связанные материалы

Что подготовить

• Адрес своей инсталляции TesLab. В примерах используется https://lab.example. Замените его адресом своего сервера; методы вызываются по пути /api/....
• Логин и пароль действующего сотрудника этой инсталляции. Здесь описан вход сотрудника, а не контрагента или оператора ОДС. Для интеграции удобно выделить отдельную учётную запись с нужным для обмена доступом.

Выбор адреса описан в статье «API TesLab: адрес сервера и первый запрос», настройка отдельной записи в статье «Учётная запись интеграции и права доступа».

Параметры входа

Отправьте JSON в POST /api/auth/gettoken. Для парольного входа используются следующие параметры:

Base64 не шифрует пароль. Используйте HTTPS. Храните пароль и токен в защищённых настройках интеграции, не записывайте их в журналы и не передавайте в адресе запроса.

Например, в Python 3 строку можно закодировать так:

import base64

pwd = base64.b64encode("Demo-pass-123!".encode("utf-8")).decode("ascii")
print(pwd)

Результат: RGVtby1wYXNzLTEyMyE=. Сохраняйте завершающие знаки =, если они есть в результате, и не вставляйте переносы строк внутрь значения.

Запрос входа

Адрес, логин, пароль и номера в примерах условные. Подставьте свой сервер, логин сотрудника и Base64 своего пароля:

curl 'https://lab.example/api/auth/gettoken' \
  -H 'Content-Type: application/json; charset=UTF-8' \
  -H 'Lang: ru' \
  -H 'Out: json' \
  --data '{"login":"integration-demo","pwd":"RGVtby1wYXNzLTEyMyE=","long":false,"etp":false}'

--data задаёт тело и метод POST. Заголовок Out: json выбирает формат ответа, Lang: ru язык сообщений. Для этого запроса токен ещё не нужен.

Успешный ответ

При успешном входе сервер возвращает HTTP 200. Ниже показан фрагмент JSON с токеном и учётной записью:

{
  "token": {
    "uid": 900301,
    "login": "integration-demo",
    "token": "LEGACY_TOKEN_EXAMPLE",
    "lifetime": "2026-11-09 17:00:00",
    "tokenid": 900401,
    "auth": "YOUR_AUTH_TOKEN"
  },
  "user": {
    "id": 900301,
    "login": "integration-demo",
    "fname": "Примеров",
    "name": "Иван",
    "oname": "Иванович",
    "status": 0,
    "certid": false
  }
}

Возьмите строку token.auth и сохраните её для следующих запросов. Это готовое значение: его не нужно расшифровывать или собирать из других полей.

Проверка сессии

Передайте полученное значение token.auth в заголовке auth. Вместо YOUR_AUTH_TOKEN подставьте всю строку из ответа, без префикса Bearer:

curl 'https://lab.example/api/auth/check' \
  -H 'Lang: ru' \
  -H 'Out: json' \
  -H 'auth: YOUR_AUTH_TOKEN'

Этот запрос выполняется методом GET. При действующей сессии сервер возвращает HTTP 200 и сведения сотрудника. Фрагмент ответа:

{
  "id": 900301,
  "login": "integration-demo"
}

Убедитесь, что это ожидаемая учётная запись. Здесь id и login находятся в корне JSON, а не внутри user, как в ответе входа.

Далее используйте тот же заголовок auth в рабочих запросах API. Получать новый токен перед каждым запросом не нужно: каждый успешный вызов auth/gettoken создаёт новую сессию. Успешная проверка сессии подтверждает учётную запись, а доступ к конкретному методу сервер проверяет отдельно.

Если запрос не выполнен

Учитывайте HTTP-статус и поля title, mess в теле ответа. Одного кода недостаточно, чтобы определить причину отказа.

Например, при неверных учётных данных ответ HTTP 403 содержит такие поля:

{
  "mess": "",
  "title": "Пожалуйста, укажите корректные логин и пароль.",
  "error": true
}

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

Продление, истечение и завершение сессии описаны в статье «Срок действия токена, проверка и завершение сессии».

Сведения о сотруднике в user

В ответе входа объект user содержит сведения сотрудника. Ниже перечислены основные поля; состав не ограничивается этой таблицей. Для простого подключения достаточно сопоставить id и login. Дополнительные сведения могут быть не заполнены.

Связанные материалы

Альтернативный способ подключения описан отдельно: «HTTP Basic для серверных интеграций».