Yii Framework

Писал issue на гит, но походу меня не понял или возможно я не правильно написал, но речь не об этом, есть вот такая проблема:

Я использую вот этот компонент: https://github.com/yiisoft/yii2/blob/ma ... ession.php
для хранения сессий в базе данных.

Настройки соответственно вот такие: Все работает сессия действительно записывается в базу данных.

Проблема 1:
Если удалить сессию из базы данных пользователя не разлогинивает с сайта. У меня так работал один проект на yii1 и там при удалении
сессии и бд пользователя выбрасывало из аккаунта. Подскажите пожалуйста почему в yii2 не разлогинивает пользователя и как это сделать?

Проблема 2:
Есть задача найти сессию определенного пользователя и разлогинить его. Данные пользователя записываются в сериализованном виде в поле data, там действительно есть идентификатор пользователя, но если искать по LIKE или регулярным выражения это достаточно долго.
Тоесть нужно как-то добавлять поле user_id в таблицу сессий и записывать туда идентификатор пользователя ну и получается переопределять компонент сессий.

Как решить эту проблему без костылей ?

1. а при удалении точно не появляется новой записи в базе? если нет, то смотрите в настройках компонента, возможно данные о логине остаются в куках
2. возьмите данные о сессии из компонента сесии или куков, должна быть связь с пользователем кроме как в поле data

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

А как я возьму куки другого пользователя, чтобы его разлогинить ?

видимо придется переопределить компонент...

а это вообще хорошая практика ? Тоесть почему этого не предусмотрели изначально разработчики ?

Стало интересно, проверил у себя, проблем с сессией нет, ни с файлами, ни с БД. При удалении сессии, пользователя разлогинивает.

По второй проблеме. Может лучше в таблицу пользователя добавить поле expire и при обработке запроса проверять его и если у пользователя время истекло делать user->logout() и отправлять на страницу логина. Соответственно, чтобы разлогинить пользователя, установить ему expire в 0.

expire уже есть в сессии, легче туда добавить поле user_id
а таблица user и так сама по себе большая, незачем туда пихать часто обновляемые данные

Первая проблема решена с помощью: Походу это даже параметр по умолчанию.

Что касается второй проблемы:
http://www.yiiframework.com/doc-2.0/yii ... ram-detail

Тут есть параметр __id, который хранит в себе идентификатор пользователя, но он записывается в поле data в таблице сессий. И делать выборку по нему весьма проблематично.

Получается остается только переопределять класс сессий и добавлять после user_id, но я до сих пор не понимаю почему это не предусмотрели разработчики ?

напишите в github плиз, типа я хочу получать сессии других пользователей и разлогинивать их

да, samdark вас не правильно понял
надо написать, что вы предлагаете feature - сохранять вместе с сессиями и user_id для поиска сессии пользователя с целью их разлогинивания в ручную.

astronin писал(а):да, samdark вас не правильно понял
надо написать, что вы предлагаете feature - сохранять вместе с сессиями и user_id для поиска сессии пользователя с целью их разлогинивания в ручную.

А мне почему-то кажется, что это будет не фича, а потенциальная дыра в безопасности.

ну говорите, раз уже начали, о чем речь?

Я так думаю. Если добавлять поле user_id в таблицу сессии, то для соблюдения единообразия, на файлах при генерации ключа сессии тоже надо включить user_id.
И получается, что если каким-то образом сервер был скомпрометирован, то потенциальному злоумышленнику облегчаем задачу по поиску сессии конкретного уже залогиненого пользователя (как часто бывает id пользователя может присутствовать в url).

Да даже тупо. Работал человек на работе, имел доступ к БД. Потом уволился. его аккаунт из системы удалили, а доступ к БД сменить забыли (всякое бывает). Зашел он туда, нашел сессию админа и сделал какую-нибудь подлянку по-тихому.

зачем трогать юзер айди. Сессии и так хорошо работают без него, тоесть по идентификатору. Юзер айди это чисто для удобства выборки для администратора. Оно по любому есть в поле data, но что бы к примеру сделать выборку пользователя, нужно использовать либо регулярки либо лайк, либо десериализацию (если версия базы позволяет), а это весьма долгий процесс даже на 20к записях.

Тоесть по ситу все, что я предлагаю это достать id пользователя из поля data и организовать его в отдельном поле user_id для удобной выборки.

nepster писал(а):Тоесть по ситу все, что я предлагаю это достать id пользователя из поля data и организовать его в отдельном поле user_id для удобной выборки.

Зачем? Мне, к примеру, это из коробки не надо. Сессии по ID юзера я искать не собираюсь. Да и вообще, не правильно это как-то, чтобы разлогинить пользователя тупо грохать его сессию.

Так что переопределяй стандартный компонент сессии

chungachguk писал(а):

nepster писал(а):Тоесть по ситу все, что я предлагаю это достать id пользователя из поля data и организовать его в отдельном поле user_id для удобной выборки.

Зачем? Мне, к примеру, это из коробки не надо. Сессии по ID юзера я искать не собираюсь. Да и вообще, не правильно это как-то, чтобы разлогинить пользователя тупо грохать его сессию.

Так что переопределяй стандартный компонент сессии

на вас свет клином не сошелся, вот другому человеку надо это из коробочки.

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

и проблем безопасности, о которых вы выше написали не будет, т.к. помоему, вы не понимаете как в yii2 сохраняются сессии в базу.

astronin писал(а): на вас свет клином не сошелся, вот другому человеку надо это из коробочки.

Я говорю о том же самом. Разработчики должны реализовывать базовые вещи, а удобство каждый должен реализовывать сам.

astronin писал(а): и проблем безопасности, о которых вы выше написали не будет, т.к. помоему, вы не понимаете как в yii2 сохраняются сессии в базу.

Тот пример с безопасностью будет, т.к. я ради интереса посмотрел у себя на локалке. Так что мне была бы более интересна защита от подмены сессии из коробки.

это и есть базовая вещь и любому админу она может понадобиться
не будет проблем, если не сделать так как вы сказали, что совершенно неумно