Я установил систему входа, которая проверяет mysql db, проверяя имя пользователя, хешированный пароль и запрещенный столбец (0 означает, что он не запрещен и является значением по умолчанию, 1 означает запрет). если они запрещены, они, очевидно, не могут loggin.
Проблема в том, что я новичок в php и имею чертовски время, пытаясь выяснить, как выйти из пользователя, который в настоящее время вошел в систему. В настоящее время мой cookie будет длиться 2 недели, и даже если я запретил пользователю , их сеанс будет оставаться активным, таким образом, у них будет нехватка на 2 недели или меньше.
Как я могу заставить пользователя повторно аутентифицироваться, не наказывая массы.
Ваш сервер знает, какой файл cookie связан с каждым пользователем. Почему бы просто не удалить этот файл cookie из таблицы «Текущие сеансы»?
Если cookie – это просто «имя пользователя, кто вошел в систему», у вас есть настоящая проблема, потому что вместо волшебного номера куки содержит реальную информацию, и становится тривиальнее подделывать. Затем злоумышленник может просто создать куки-файл, в котором говорится: «Я [admin], и я вошел в систему», и это, очевидно, гораздо большая проблема. Поэтому, если вы не можете просто удалить файл cookie сеанса из таблицы «известных файлов cookie», чтобы решить эту проблему, вам придется больше беспокоиться.
Если вы полностью используете свою систему аутентификации (это правда, BTW), вам просто нужно отключить значение сеанса, которое содержит их аутентифицированный статус. Итак, если вы использовали:
<?php session_start(); if(isset($_SESSION['isloggedin']) && isBannedUser()) { session_unset(); session_destroy(); } ?> Псевдокод выше вызывает фиктивную функцию, называемую isBannedUser() чтобы определить, запрещены ли они или нет. Если они есть, в моем примере выше я вызываю session_unset() чтобы отключить все значения, хранящиеся в $_SESSION а затем session_destroy() чтобы полностью закрыть сеанс. Некоторые, вероятно, утверждают, что вам может не понадобиться отменить, если вы уничтожаете, но я только что привык очищать все переменные и значения, которые я делаю в коде.
Это должно быть на каждой странице, чтобы вы проверяли, запрещены ли они как можно чаще. При уничтожении $_SESSION пользователь фактически выбивается из любой части вашего сайта, требующей аутентификации. Вам нужно будет внедрить вспомогательный код в рабочий процесс входа в систему, в результате которого запрещенный пользователь может снова войти в систему.
Надеюсь, это полезно.
Если вы сохраняете данные сеанса в базе данных, удалите строку со своей информацией о сеансе. Или удалите файл, если используете файлы. Затем загрузка следующей страницы, система входа в систему не сможет проверить свою регистрационную информацию (так как нет информации для этого сеанса) и попросить их повторно войти в систему.
В файловой системе сеансов поддерживайте счетчик где-нибудь, который запускает периодическую проверку базы данных для обновлений, например:
<?php session_start(); $_SESSION['hits_since_last_verification']++; if ($_SESSION['hits_since_last_verification'] > 100) { $banished = ... // get banishment flag from database if ($banished) { $_SESSION['loggedIn'] = FALSE; } } ?>
а затем решить, как долго вы хотите, чтобы запрещенный пользователь был разрешен для продолжения кокетки вокруг сайта до тех пор, пока данные сеанса не будут обновлены, и они будут загружены.
Другим вариантом является внешний скрипт, который проходит через каталог хранения сеанса, загружает каждый поочередно, проверяет, запрещен ли пользователь, и, при необходимости, обновляет файл сеанса. Но это было бы болезненно даже при умеренно загруженной системе, когда вы открываете / неэриализовываете / проверяете изгнание / обновление / ресериализацию потенциально тысяч файлов сеансов каждые X минут.
возможно, вы хотите сохранить сеансы в другой таблице и удалить их при запрете пользователя.
вы знаете. проверяйте таблицу каждый раз, когда пользователь загружает сеанс, и если пользователь не существует. удалите файл cookie и уничтожьте сеанс (отправив его в индекс вашего сайта)
Вы можете сохранить идентификатор пользователя в сеансе и по каждому запросу, вы проверяете, запрещен ли он (SQL-запрос). Если это правда, вы уничтожаете его сессию, поэтому он вынужден повторить проверку подлинности. Конечно, это не так, потому что он запрещен.