Seek&Destoy

[Сергей Кудрин]

Можно ли как-то принудительно сделать logout для пользователя, который бродит по сайту, но еще не знает, что модератор уже поставил ему user.is_active = False в качестве наказания?

Получается этакий человек-зомби - уже прибили, но пока он сам не выйдет - ничего с ним не сделаешь. Даже становится не по себе, если вспомнить, что у пользователей есть привычка вообще никогда не нажимать "Выход".

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

[Владимир Прохода]

Напишите миддлеварь, которая проверить is_active и разлогинит, если нужно.

2012/11/18 Сергей Кудрин <smo...@gmail.com>

Можно ли как-то принудительно сделать logout для пользователя, который бродит по сайту, но еще не знает, что модератор уже поставил ему user.is_active = False в качестве наказания?

Получается этакий человек-зомби - уже прибили, но пока он сам не выйдет - ничего с ним не сделаешь. Даже становится не по себе, если вспомнить, что у пользователей есть привычка вообще никогда не нажимать "Выход".

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

--
 
 

--
Если есть трудное дело, поручите его лентяю: он найдет более легкое решение.

[Serge Matveenko]

2012/11/18 Сергей Кудрин <smo...@gmail.com>:

> Можно ли как-то принудительно сделать logout для пользователя, который
> бродит по сайту, но еще не знает, что модератор уже поставил ему
> user.is_active = False в качестве наказания?

В общем, да, вы можете написать мидлеварь.

> Получается этакий человек-зомби - уже прибили, но пока он сам не выйдет -
> ничего с ним не сделаешь. Даже становится не по себе, если вспомнить, что у
> пользователей есть привычка вообще никогда не нажимать "Выход".

Но на самом деле, причин для паники нет, достаточно задуматься.

> Страшно подумать, что он понапишет в коментах, к примеру, если прочтет
> сообщение от модератора, где сказано, что его больше не любят и не ждут на
> этом сайте.

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

Если вы все написали правильно, то ваш пользователь будет волшебным
образом получать отказ в любом действии, в котором вы проверяете
свойство is_active (т.е. везде где он вообще что-то может сделать).
Джанговский бэкенд по-умолчанию делает это в user.has_perm.

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

Вообще, я посмотрел код и удивился. is_authenticated, а значит и
login_required никак не проверяют свойство is_active. Очень странно.

--
Serge Matveenko
mailto: se...@matveenko.ru
github: http://lnkfy.com/1
linkedin: http://lnkfy.com/S

[Nikolay Fominykh]

Или в бэкграунде поставьте демонюгу, которая бродит по всем сессиям, и убивает сессии в которых лежит id пользователя с is_active = False. Чуть сложнее, но request останется легким.  

18 ноября 2012 г., 20:58 пользователь Владимир Прохода <vladimi...@gmail.com> написал:

--
 
 

[livskiy]

Имо, сигнал повесить на user.savе, там и вылогинить если что.

18 ноября 2012 г., 23:40 пользователь Nikolay Fominykh <niko...@gmail.com> написал:

--
 
 

[Nikolay Fominykh]

Сигналы дергаются при каждом сохранении. Т.е. все хорошо до тех пор пока нету действий с Users.objects.all || filter... 

А с миддлеварей все хорошо, пока их 18+ не становится. 

ИМХО жирно для такого редкого случая их юзать. 

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

18 ноября 2012 г., 21:42 пользователь livskiy <liv...@gmail.com> написал:

--
 
 

[livskiy]

Не понял кейс с Users.objects.all || filter, что с ним не так?

18 ноября 2012 г., 23:52 пользователь Nikolay Fominykh <niko...@gmail.com> написал:

--
 
 

[Nikolay Fominykh]

Если есть задача, в которой нужно обойти всех пользователей и что-нибудь с ними сделать(баланс свести с транзакциями например) - то она станет значительно медленее выполнятся - сделайте tail -f /query_log_for_db_you_use, чтобы посмотреть как работает сигнал... Хотя общие задачи лучше без ORM решать вообще. Возможно у меня кризис и я даю опасные советы.

Сигналы и миддлевари - для общих случаев. Разлогин пользователя - частный случай. 

[livskiy]

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

19 ноября 2012 г., 0:11 пользователь Nikolay Fominykh <niko...@gmail.com> написал:

Если есть задача, в которой нужно обойти всех пользователей и что-нибудь с ними сделать(баланс свести с транзакциями например) - то она станет значительно медленее выполнятся - сделайте tail -f /query_log_for_db_you_use, чтобы посмотреть как работает сигнал... Хотя общие задачи лучше без ORM решать вообще. Возможно у меня кризис и я даю опасные советы.

Сигналы и миддлевари - для общих случаев. Разлогин пользователя - частный случай. 

--
 
 

[Nikolay Fominykh]

Короче, всё от полученного негативного опыта зависит. Мне проще зоопарк содержать и держать всякого рода странные задачи подальше от веб-морды. :)

18 ноября 2012 г., 22:39 пользователь livskiy <liv...@gmail.com> написал:

--
 
 

[Mikhail Kashkin]

Думаю предложенный вариант не очень хорошая практика. Пусть лучше пользователь остается залогиненным, но ограничен в правах. Переводите его в  группу у которой права r/o и выводите угрожающее сообщение на страницах. 

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

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

2012/11/18 Сергей Кудрин <smo...@gmail.com>

Можно ли как-то принудительно сделать logout для пользователя, который бродит по сайту, но еще не знает, что модератор уже поставил ему user.is_active = False в качестве наказания?

Получается этакий человек-зомби - уже прибили, но пока он сам не выйдет - ничего с ним не сделаешь. Даже становится не по себе, если вспомнить, что у пользователей есть привычка вообще никогда не нажимать "Выход".

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

--
Mikhail Kashkin

http://comfort.ly/ 

http://www.vurt.ru/ 

[Serge Matveenko]

2012/11/19 Mikhail Kashkin <mkas...@gmail.com>:

> Думаю предложенный вариант не очень хорошая практика. Пусть лучше
> пользователь остается залогиненным, но ограничен в правах. Переводите его в
> группу у которой права r/o и выводите угрожающее сообщение на страницах.

Вот тут важная мысль. Имхо, active по его сути в коде джанго стоит
использовать только для активации пользователя. Т.е. он сначала
is_active=False, потом активируется и становится is_active=True. А
дальше все должно делаться логикой вашего приложения. Т.е. если бан,
то is_banned = True, если права, то права. Тогда у вас сразу станет
все хорошо: вы сможете быть уерены, что юзеры получат только то, что
им пожно получить, и увидят те алерты, которые им должно увидеть.

В таком случае, тому же забаненому пользователю можно оставить права
написать аппеляцию, например.

[マギクアルセニ]

Вообще, чтобы не бродить по всем сессиям, можно при логине записывать в Redis в специальном ключике для данного пользователя идентификаторы сессий (у пользователя их может быть несколько). А на изменение модели User действительно добавить сигнал, в котором этот ключик будет читаться и сессии пользователя будут удаляться.

Главное проследите, чтобы старые (истёкшие) сессии периодически удалялись.

2012/11/18 Nikolay Fominykh <niko...@gmail.com>

--
 
 

[Pavel Reznikov]

охлол

еще и редис сюда присунуть

//wbr Pavel Reznikov <pashka....@gmail.com>

2012/11/19 マギクアルセニ <aruseni...@gmail.com>

--
 
 

[マギクアルセニ]

А что не устраивает? По-хорошему, надо в любом случае сессии именно в нём хранить (https://github.com/martinrusev/django-redis-sessions). По крайней мере, так ты избавляешься от дополнительных запросов к БД при каждой проверке сессии.

2012/11/19 Pavel Reznikov <pashka....@gmail.com>

--
 
 

[Mikhail Kashkin]

Шах и мат, зомби!

2012/11/20 マギクアルセニ <aruseni...@gmail.com>

А что не устраивает? По-хорошему, надо в любом случае сессии именно в нём хранить (https://github.com/martinrusev/django-redis-sessions). По крайней мере, так ты избавляешься от дополнительных запросов к БД при каждой проверке сессии.