Авторизация пользователя

Перед работой с чатом необходимо авторизовать пользователя. Без вызова authorize(...) сообщения не будут отправляться.

Порядок вызовов

Параметр auth опционален (ChatAuth?): передайте null, если кастомная серверная авторизация не используется. Значения полей ChatAuth согласуются с поддержкой edna.

Вызывайте authorize(...) после init(...) или после onInitComplete для initAsync (см. Жизненный цикл).

Если используете push, передайте FCM/HCM-токен через setFCMToken(...) / setHCMToken(...) до authorize(...) — тогда токен уйдёт на сервер сразу при регистрации устройства. См. Настройка уведомлений.

Основной метод

Минимальный вызов (без кастомной серверной авторизации):

chatCenterUI.authorize(
    ChatUser(identifier = "YOUR_USER_UUID"),
    null
)

Полная форма со всеми параметрами:

import edna.chatcenter.core.ChatAuthType
import edna.chatcenter.core.config.ChatAuth
import edna.chatcenter.core.config.ChatUser

val accessTokenFromBackend: String? = "YOUR_ACCESS_TOKEN"
val signatureFromBackend: String? = "YOUR_SIGNATURE"

chatCenterUI.authorize(
    ChatUser(
        identifier = "YOUR_USER_UUID",        // обязательный — стабильный непустой ID пользователя
        name = "Иван Петров",                 // опционально
        data = mapOf("department" to "support") // опционально — данные для оператора
    ),
    ChatAuth(
        token = accessTokenFromBackend,
        scheme = "retail",
        method = ChatAuthType.HEADERS,        // HEADERS (по умолч.) или COOKIES
        signature = signatureFromBackend,
        isEncrypted = false                   // true, если identifier зашифрован вашим бэкендом
    )
)

Модель ChatUser

data class ChatUser(
    val identifier: String,
    val name: String? = null,
    val data: Map<String, String>? = null
)

Поле	Тип	Обязательный	Описание
identifier	String	Да	Уникальный стабильный ID пользователя
name	String?	Нет	Имя для отображения у оператора
data	Map<String, String>?	Нет	Произвольные строковые данные для оператора (см. ниже)

Контракт identifier

SDK на входе проверяет client.identifier.isNotBlank() и при пустой строке бросает IllegalArgumentException ещё до запроса к серверу.

осторожно

identifier должен быть уникальным, постоянным и устойчивым к подбору. Не используйте телефон, email или другие персональные данные в открытом виде. Если без них не обойтись, используйте RSA-шифрование и установите isEncrypted = true.

Рекомендуемые ключи data: Map<String, String>

SDK передаёт data на сервер без изменений — обработка ключей определяется настройками очереди в edna и вашим бэкендом. Имена ниже — соглашение для единообразной интерпретации.

Ключ	Назначение	Пример
clientId	Внешний идентификатор клиента в вашей CRM.	"7281"
clientPhone	Телефон в формате E.164 (если разрешено политикой).	"+71234567890"
clientEmail	Email клиента.	"user@example.com"
firstMessage	Текст первого сообщения для автооткрытия диалога. SDK передаёт значение как есть; автоотправка выполняется на стороне edna и зависит от настроек очереди.	"Здравствуйте, у меня вопрос по заказу 12345"
externalContacts	JSON-строка с дополнительными контактами / маркерами для роутинга.	"""{"channel":"mobile_app"}"""
department	Очередь / отдел, в который должен попасть диалог.	"support"
language	Предпочитаемый язык клиента.	"ru"

Структурированные данные (например, externalContacts) сериализуйте в JSON-строку.

Модель ChatAuth

Поле	Тип	Обязательный	Описание
token	String?	Нет	Токен авторизации, выданный вашим бэкендом
scheme	String?	Нет	Схема авторизации
method	ChatAuthType	Нет (по умолчанию HEADERS)	Способ передачи данных авторизации
signature	String?	Нет	Подпись, выданная вашим бэкендом
isEncrypted	Boolean	Нет (по умолчанию false)	true, если ChatUser.identifier зашифрован вашим бэкендом. SDK сам ничего не шифрует — флаг лишь подсказывает серверу, как трактовать identifier

ChatAuthType

Значение	Описание
HEADERS	token передаётся в HTTP-заголовке Authorization, scheme — в дополнительном заголовке X-Auth-Schema (по умолчанию)
COOKIES	Те же значения передаются в HTTP-заголовке Cookie в виде Authorization=<token>; X-Auth-Schema=<scheme>

Полный пример (Kotlin и Java)

SDK передаёт token в заголовок Authorization без изменений — если ваш бэкенд требует префикс Bearer , добавьте его сами в значении token.

Kotlin

val user = ChatUser(
    identifier = "YOUR_USER_UUID",
    data = mapOf("department" to "support")
)

val auth = ChatAuth(
    token = "YOUR_ACCESS_TOKEN",
    scheme = "retail",
    signature = "YOUR_SIGNATURE"
)

chatCenterUI.authorize(user, auth)

Java

import java.util.HashMap;
import java.util.Map;
import edna.chatcenter.core.config.ChatUser;
import edna.chatcenter.core.config.ChatAuth;
import edna.chatcenter.core.ChatAuthType;
import edna.chatcenter.ui.visual.core.ChatCenterUI;

Map<String, String> userData = new HashMap<>();
userData.put("department", "support");

ChatUser chatUser = new ChatUser(
    "YOUR_USER_UUID",
    null,
    userData
);

ChatAuth chatAuth = new ChatAuth(
    "YOUR_ACCESS_TOKEN",
    "retail",
    ChatAuthType.HEADERS,
    "YOUR_SIGNATURE",
    false
);

chatCenterUI.authorize(chatUser, chatAuth);

Логаут

Метод	Когда использовать
logout()	Выход пользователя из аккаунта
deauthorizeUser()	Выход из авторизованной зоны (пин-код)

logout() — полный выход

Отправляет серверу CLIENT_OFFLINE, закрывает WebSocket и удаляет локальные данные SDK (БД, SharedPreferences), кроме FCM/HCM push-токенов.

deauthorizeUser() — только сброс пользователя

Локально удаляет только ChatUser и ChatAuth. БД и SharedPreferences не трогаются, сессия на сервере не закрывается. Используется для блокировки UI пин-кодом без потери истории; повторный authorize(...) с тем же identifier возобновляет ту же сессию.

// Полная очистка локальных данных
chatCenterUI.logout()

// Локальное удаление ChatUser/ChatAuth (сессия на сервере не закрывается)
chatCenterUI.deauthorizeUser()

FCM/HCM-токены и logout()

logout() не очищает FCM/HCM push-токены: SDK хранит их в отдельном файле SharedPreferences (edna.chatcenter.ui.cloudMessagesPreferences), который не задевается стандартной очисткой. Подробности и рекомендуемый workaround — в Жизненный цикл → §4 Выход пользователя.

Смена пользователя

При вызове authorize(...) с другим identifier SDK сам инициирует logout() предыдущего пользователя, а новую регистрацию откладывает до завершения логаута (внутри SDK она автоматически вызовется повторно). Поэтому явный logout() перед сменой пользователя не нужен, но authorize() в этом сценарии возвращает управление до того, как регистрация фактически произошла — наблюдайте состояние через ChatCenterUIListener / ChatState, если поведение приложения зависит от готовности сессии.

Связанные разделы

• Инициализация SDK
• Жизненный цикл
• События и слушатели
• Ошибки
• Отправка сообщений