Хорошо, опишите реакцию продукта для следующих кейсов: - не забаненый пользователь авторизуется; - забаненый пользователь авторизуется; - авторизованный пользователь банится; - забаненый авторизованный пользователь разбанивается.
Пользователю отправляется уведомление - наложено то-то, заканчивается тогда-то. Если пользоваль что-то пытается запостить, ему отбой, с описанием причины. Например одно сообщение в час, то есть нужно еще и время последнего сообщения извлекать. Если бан полный, то не надо. --- Добавлено --- Если же ограничение на просмотр чего-нибудь, то немног по-другому.
Опишите русскими словами, какова должна быть реакция продукта в данных случаях. Какие ещё строки? Поиграю в системного аналитика между Вами (как заказчиком продукта) и Вами (как исполнителем заказа). ))
1) проверяем пользователя на существования в бд, если существует разрешаем вход 2) проверяем пользователя не стоит ли у него бан, если проверка прошла проверяем на существования в бд 3) вставляем запись в таблицу банс, если пользователь нарушил, баним пользователя 4) проверяем время разбана, если время истекло разбаниваем забаненого авторизованного пользователя Надеюсь я вас правильно понял, что вы от меня хотите.
Увы и ах ( Вы описали внутреннее частичное понимание со стороны разработчика на сумбурный кейс. Пожалуйста, распишите, что должен делать продукт в каждом из случаев (если где-то будут одни и те же шаги, нестрашно, копипастите).
опишите для одной строки, пусть будет даже для другого примера это описание, а то я вас не понимаю, что за слоганы, что от меня хотите. Спасибо.
@_ne_scaju_, как проявляется бан? Это же не просто статус (плюс время). Наверное, при бане пользователю запрещено выполнять какие-то действия. Вплоть до возможности входа под учетными данными забаненного акка.
только не понять, зачем type тип бана?) если юзер попал в таблицу, его uid уже находится то значит он в бане
Ограничения бывают всякие. Например - одно сообщение в час. Запрет комментировать новости с особой пометкой. Запрет на доступ в некоторые разделы сайта. Прочее. Естественно, если такой градации нет, то эта колонка лишняя. И конечно же, вся система ограничений имеет смысл, если к контенту имеют доступ только авторизованные пользователи.
а если пользователь авторизован, чаще всего идет запрет на добавления записей например в пост новость, или ограничивают в плоть до запрета входить в кабинет свой? Как чаще всего, чтобы суть понимать нужно мне это поле или не нужно.
Не знаю, у меня такой статистики нет. Вас выше спрашивали, чего вы, собственно, пользователю ограничить хотите? Я ответа не видел.
Странные у тебя вопросы. Всё от задачи зависит. Если делаешь проект на заказ - делаешь так, как согласовано с заказчиком. Если делаешь проект для себя, то делаешь, как душе угодно. Как сам считаешь правильно. Всё делается, и запрет определённых действий, и полный запрет аутентификации, всё по разному. Какая тебе разница, как чаще? У тебя есть проект, у проекта есть какая-то цель. Или цель поиграться с разными видами бана чисто для прикола? Ну так поиграйся.
есть проект, который делаю для себя, пока чисто играюсь с ним, вот и не знаю что делать лучше, наверное просто закрывать банить к определенным действиям да и все. --- Добавлено --- а я вопросов не понял, ограничить скорее хочу, запрет писать комменты под постами, например если уж через чур нарушил тогда запрет вход в кабинет.
Ну, тогда без поля `type` не обойтись. Нужна отдельная функция или подключаемый в нужном месте(обработка формы авторизации и формы добавления комментариев) скрипт, проверяющая состояние пользователя в таблице с ограничениями. Кроме того, нужен отдельный код для принудительного закрытия всех существующих сессий пользователя, при наложении такой санкции, то есть где-то нужно хранить их ID.
смысле где то их id хранить есть таблица пользователей есть таблица баннов, и там и там хранится id пользователя. А еще куда предлагаете сохранить id?
Сессии имеют свой уникальный ID. Обычно они хранятся в файлах в специальной директории. В зависимости от сложности используемого способа авторизации, у одного пользователя их может быть несколько. Как правило, сверка паролей\логинов, и прочего, происходит на этапе авторизации, и далее вся необходимая информация извлекается из сессии. То есть. Все наложенные санкции касаемые доступа в аккаунт, вступят в силу только после закрытия сессии. И если это не сделать принудительно(удалить файл(ы) сессии), то придется ждать пока пользователь не нажмет "выход".
ок, разве когда я поставлю пользователю бан, при этом очищу сессию по его uid при обновлении страницы он уже будет не авторизован. Обязательно удалять файлы, или уничтожения сессии помогает? --- Добавлено --- еще вопрос такой, делаю для бана делаю три поля: login: end_ban: comment_ban а вот еще поле type (будет в виде массива, где будет перебираться, всякие ограничения) - поле это тоже должно присутствовать?