# Отслеживание сессий пользователей

### Выбор хранилища
- оценить объем чтения: количество запросов от залогиненых пользователей
- оценить объем записи: логины/разлогины/обновление информации о сессии (например ip)
- оценить число записей: количество событий логина по user_sessions сгруппированные по месяцам даст хорошее представление о динамике роста
- поговорить с админами: если mysql — ок, можно рассмотреть вариант подселения к user_sessions, если не ок, искать альтернативы schemaless kv

### Вопросы

#### ? Какая длина истории / максимальное количество сессий

На примере gitlab у каждого пользователя может быть не больше 100 устройств. Для контроля размера датасета нам нужно свое разумное ограничение. Если решим хранить и отозванные токены, ограничение будет распространяться и на них.

Ratio такое: мошенник может залогиниться, чего-то там поделать, и удалить свою сессию в UI. Артефактом того, что кто-то заходил останется только отправленное письмо.

В протухших по времени сессиях толку нет, такие можно спокойно удалять.

#### ? Каким должен быть ID сессии

В первом приближении была идея собрать с девайса некий "отпечаток", которого будет достаточно для генерации ID сессии. На деле, у данных которые мы можем собрать нет достаточной кардинальности. Что важнее, смысла в этом тоже нет.

Проще всего в качестве id сессии использовать случано сгенерированный UID. А при создании сессии сохранять доступную инфу: ip, браузер, вид устройства и т.п.

ID должен быть уникальным только для конкретного ID пользователя, и при этом достаточно коротким чтобы шифроваться внутри boobs. Можно использовать случайный 8-символьный короткий UID. GUID (если такой, вообще, потребуется) вычислять как хэш от (user_id, uid).

#### ? Обновления информации о сессии / валидация сессии

Положим я делаю реквест и передаю валидные авторизационные данные. Но бэкэнд видит, что параметры текущего запроса отличаются от тех, что были в момент генерации сессии, например:

- изменился IP: в 4/3/2/1 октете, или IP принадлежит другой автономной сети;
- изменился агент: было приложение, стал браузер. Был chrome, стал FF.

Что делать с таким запросом: пропустить? если да то обновить ли инфу в сессии? если нет, то отозвать ли сессию вообще, видимо она скомпрометирована?

*В текущих условиях ответ на этот вопрос важен только в разрезе оценки объема записи. Саму логику можно менять по ходу развития событий*

#### ? Время жизни сессии

Отталкиваемся от текущей жизни boobs - 120 дней.
Каждый новый запрос на сайт должен обновлять время жизни (имеет смысл заморочиться и обновлять время не каждый раз, а только при первом заходе в день).

#### ? Как быть с su

У нас есть `suboobs`

#### ? Политика уведомлений

Положим, я использую браузер в режиме инкогнито и постоянно заново логинюсь на сайте. В самом простом варианте письмо будет приходить на каждый логин.

*Как часто встречаются такие персонажи можно прикинуть по user_sessions.*

В будущем можно рассмотреть способы борьбы с подобным спамом:
- переиспользовать существующую сессию, если все ее параметры совпадают (в рамках разумного временного периода) — это если предполагать, что кука потерялась;
- оживлять разлогиненную (но не отозванную) сессию (в рамках разумного временного периода) — если предполагать, что пльзователь разлогинился

#### ? Миграция boobs

Нужен механизм плавной миграции со старых boobs на новые, содержащие id сессии, чтобы массово не разлогинивать народ.

Видимо, при миграции сессии будут создаваться не в момент логина, а при первом авторизованном запросе со старыми boobs. Вряд ли при этом стоит рассылать письма.

#### ? Как оповещать

Email есть не у всех, Sms? telegram? push? Как исключать канал доставки? если я только что установил приложение и залогинился в нем — нельзя сюда же слать пуш, что я залогинлся.

#### ? Какую инфу собирать

- вендор + версия браузера
- мобильный/десктоп
- ip клиента
- платформа (bitness)
- модель девайса