Користувачі, що увійшли: передача токена

За замовчуванням помічник не знає, хто з ним говорить. У додатку цього замало: «покажи мої неоплачені рахунки» вимагає, щоб ваш API знав, який користувач питає. Віджет передає власний токен користувача, а ваш інструмент передає його далі вашому API.

Три рядки у вашому додатку

// після входу і на кожному оновленні токена:
Shukai.setUser(userToken);
// при виході:
Shukai.clearUser();
Shukai.clearHistory(); // на спільному браузері — див. нижче

userToken — будь-який рядок у стилі bearer, який приймає ваш сервер: не cookie (ми викликаємо ваш сервер напряму, і cookie з нами не їдуть), в ідеалі короткоживучий і вузько обмежений, бо він проходить через наші сервери. Ми поводимося з ним як із секретом — ніколи не зберігаємо, не логуємо, не показуємо моделі, — та вузький токен усе одно є доброю гігієною. Довший за 8 192 символи ігнорується, а не обрізається.

setUser і clearUser — стан, а не черга: тримаються в пам’яті, читаються заново на кожному повідомленні, їх безпечно викликати до монтування віджета; перемагає найновіше значення.

Один плейсхолдер у вашому інструменті

У заголовках власного інструмента, в панелі:

Authorization: Bearer {{user}}

{{user}} підставляється лише в момент HTTP-виклику, як секрет. Ваш сервер перевіряє його так само, як перевіряє запит із вашого власного фронтенду: для вас це звичайний автентифікований запит. Коли токен не передано — анонімний відвідувач — заголовок, що складається лише з Bearer {{user}}, відкидається, а не надсилається порожнім, а 401 чи 403 від вашого сервера каже помічнику, що відвідувач, схоже, не увійшов. Плейсхолдери.

Чому токен, а не id

Сирий id користувача в кадрі віджета можна було б підробити: ключ віджета публічний, тож будь-хто міг би надіслати чужий id і прочитати чужі дані. Справжній токен — це посвідчення, яке відвідувач може пред’явити лише за себе. У цьому вся ідея.

Куди токен їде

Віджет надсилає його як user_token з кожним повідомленням розмови і з кожним проактивним запитом. Рантайм передає його у виклик інструмента і більше нікуди: ні моделі, ні в лог, ні в базу даних. Кеш відповідей інструмента ключується за всім розв’язаним запитом разом із заголовками, тож відповідь, отримана з токеном одного користувача, ніколи не віддається іншому.

Вихід на спільному пристрої

clearUser() забуває токен. Він не стирає історію розмов на пристрої, яку віджет тримає до семи днів, прив’язану до віджета, а не до користувача, — інакше наступна людина, що увійде на тому самому браузері, побачила б і могла б продовжити чати попереднього відвідувача. Викликайте і clearHistory(). Ці два навмисно окремі: сесія, що просто закінчилася, забуває, хто користувач, але за екран ніхто інший не сів.

Лише користувачам, які увійшли

На вкладці Встановлення віджета є перемикач «Лише користувачам, які увійшли». Коли він увімкнений, асистент не з’являється, доки ваша сторінка не викличе Shukai.setUser(token), і зникає знову після Shukai.clearUser() — тож екрани входу, реєстрації й пароля, які ніколи не викликають setUser, нічого не показують, а вихід одразу прибирає його з екрана. Жодного списку сторінок вести не треба.

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

Це вирішує лише, де асистента видно. Ключ віджета публічний, і наші сервери не відмовляють повідомленню без токена користувача. Для сторінок, а не користувачів, на тій самій вкладці є «На всіх сторінках» · «Усюди, крім» · «Лише на цих сторінках» — Налаштування.

Наша панель як приклад

Панель видає 15-хвилинний токен власнику, що увійшов, передає його в Shukai.setUser, а інструменти пошуку її ко-пілота викликають власний API панелі з Bearer {{user}} — із тим самим обмеженням на власника, що й сама панель. У її ко-пілота увімкнено «Лише користувачам, які увійшли», тому на екрані входу асистента немає. Ваш додаток робить те саме зі своїми токенами.