Как удалить сессию из БД после истечения срока?

Question

[Nik Faraday]

Здравствуйте!

Пытаюсь реализовать схему авторизации на основе сессий. По ТЗ их нужно хранить в БД, но я не совсем разобрался с этой темой и механизмами работы с этим, по этому могу быть где-то не прав.

Вопрос состоит в том, что после истечения срока жизни сессии или во время не активности её нужно удалить из базы данных. Меня интересует сам механизм определения, когда это нужно делать и как. При авторизации всё понятно (более-менее), т.е. есть некоторое событие во время которого создаётся сессия, заносится в БД, а её Id закидывается в session-storage.

Для обновления времени активности так же понятно, т.к. нужно просто поставить middle-war'у, которая будет брать id из session-storage, по нему искать эту сессию в БД (сначала в кэше) и делать обновления данных.

Но не совсем понял механизм, как сделать sign-out при не активности или полном истечении времени сессии. Единственное что приходит в голову это background tasks, но думаю, что есть более нормальные решения этой проблемы.

Comments

[Wispik]

background task вполне нормальное решение

Answer 1

[MVV]

В ASP.NET Core есть стандартный механизм сеансов (ISession): https://learn.microsoft.com/aspnet/core/fundamenta...
Работает он на базе распределенного кэша (IDistributedCache), который штатными средствами можно базировать на MS SQL и на Redis (и, возможно, есть дополнительные сторонние пакеты для базирования на других СУБД,). Идентифкатор сессии хранится в куки (настраеваемой), по умолчанию - HTTP-only (но это настраивается).
Механизм устаревания сеансов там есть, параметры тоже можно настроить.
Кароче, если нет причин обязательно делать свой велосипед (типа, для учебной задачи) можно использовать этот стандартный механизм.
Правда идея использовать этот механизм именно для авторизации у меня вызывает некоторые неясные опасения: он, вообще-то, не для того сделан. А именно для авторизации (плюс аутентифкация) в ASP.NET Core тоже есть штатное решение (Identity и политики авторизации). И вообще, аутентифкация/авторизация - это такое место, где легко накосячить, а потому лучше там обходиться без своих велосипедов.

Comments

[Nik Faraday]

Первый раз работаю с сессиями, плюс стоит задача хранить сессии в БД. Не очень разобрался с этой темой, по этому есть что есть...

Знаю, что сессии используют временное хранилище session-storacge для хранения данных пользователя, но как это всё привязать к БД? Логично, я принялся это всё реализовывать через EF Core, Middleware и DbContext. Для обеспечения оптимизации добавлен Redis cache.

Конкретно эта часть программы выглядит крайне бредово, т.к. кроме многих функций авторизации (валидация, проверки и т.д.), добавления значения состоит из трёх частей:

• Добавление данных в БД
  
• Добавление данных в кэш
  
• Добавление данных в session-storage через HttpContext.Session
  

Т.к. сессии должны храниться в БД, немного не понял что нужно хранить в session-storage и как правильно манипулировать этими данными

[MVV]

С сессиями (они же, в русском переводе документяции MS - сеансы) есть два варианта.
Первый вариант - хранить все состояние на клиенте, для этого собственно используется session storage, а когда его раньше не было, то все гонялось туда-сюда через запросы и ответы (например, были такие ASP.NET Web Pages, AFAIK они имено так работали). Естественно, никакую БД на сервере к этому прикрутить было нельзя, да и не нужно.
Второй вариант - хранить состояние на сервере, а на клиенте иметь только идентификатор этого состояния (обычно он хранится и передается в куки, но можно хранить и в session storage). Упомянутые выше сессии в ASP.NET Core относятся к этой категории. Состояние, которое они могут хранить - это пары ключ(строка)-значение(массив байтов), т.е. все, что в этот массив может быть преобразовано (сериализовано): строки, числа, POCO-объекты DTO...

[Nik Faraday]

MVV, иными словами, на правильно ли я пути, или всё же над чем-то нужно поработать?

Answer 2

[Василий Банников]

1. Можно сессии хранить в чём-то типа редиса - там можно задавать ttl
2. При хранении в обычной реляционке - можно на всякие события аутентификации, когда ты читаешь таблицу сессий - смотреть на ttl и удалять просроченные.
3. Сверху ещё добавляем какую-нибудь задачу в cron, которая будет раз в сутки чистить.

Но не совсем понял механизм, как сделать sign-out при не активности или полном истечении времени сессии. Единственное что приходит в голову это background tasks, но думаю, что есть более нормальные решения этой проблемы.

Не обязательно удалять сессию сразу после её истечения - всё равно же при запросах проверяешь время действия.