Прямо сейчас я застрял между использованием собственного управления сессиями PHP или созданием собственной (сеансовой) системы на основе MySQL, и у меня есть несколько вопросов относительно обоих.
Помимо фиксации сеанса и захвата сеанса, существуют ли другие проблемы с использованием собственного кода обработки кода PHP? У обоих из них есть легкие исправления, но все же я вижу, как люди пишут собственные системы для обработки сессий, поэтому мне интересно, почему.
Будет ли обработчик сеанса MySQL работать быстрее, чем собственные сессии PHP? Предполагая стандартную (не «память») таблицу.
Есть ли какие-либо существенные недостатки в использовании session_set_save_handler ? Я могу полностью соответствовать моим стандартам (кроме имен). Плюс мне лично нравится идея использовать $_SESSION['blah'] = 'blah' vs $session->assign('blah', 'blah') или что-то в этом роде.
Есть ли там хорошие ресурсы сеанса php, на которые я должен обратить внимание? Последний раз, когда я работал с сессиями, было 10 лет назад, поэтому мои знания немного застоялись. Поиски Google и Stackoverflow дают множество базовых, явно плохо написанных руководств и примеров (Храните имя пользователя + md5 (пароль) в cookie, затем создайте сеанс!), Поэтому я надеюсь, что у кого-то есть некоторые законные ресурсы с более высокой брови.
Независимо от моего выбора, я буду принуждать только печенье. Это что-то не так? Сайты, на которых работает этот код, имеют средние пользователи в средней среде безопасности. Я помню, что это была огромная проблема в последний раз, когда я использовал сеансы, но идея использования сессий в URL-адресах очень нервничает.
Ответ на 2) зависит от id. Позвольте мне объяснить: для того, чтобы обработчик сеанса работал правильно, вам действительно нужно реализовать какой-то механизм блокировки и разблокировки. MySQL имеет функции блокировки таблицы и разблокировки таблицы. Если вы не выполняете блокировку таблицы в обработчике сеанса, вы рискуете иметь условия гонки в запросах на основе ajax. Поверь мне, ты не хочешь этих.
Прочитайте эту подробную статью, в которой объясняется состояние гонки в пользовательском обработчике сеансов :
Итак, если вы добавите LOCK TABLE и UNLOCK TABLE к каждому сеансовому вызову, как вам нужно, тогда ваш пользовательский обработчик сеанса станет немного медленнее.
Одна вещь, которую вы можете сделать, чтобы сделать ее намного быстрее, – это использовать таблицу HEAP для хранения сеанса. Это означает, что данные будут храниться только в ОЗУ и никогда не записываться на диск. Это будет работать быстро, но если сервер опустится, все данные сеанса будут потеряны.
Если вы в порядке с тем, что сеанс теряется, когда сервер идет вниз, вместо этого вы должны использовать memcache в качестве обработчика сеанса. Memcache уже имеет все необходимые функции для использования обработчика сеанса php, все, что вам нужно для этого, установить сервер memcache, установить расширение memcache php, а затем добавить что-то подобное вам php.ini
[Session] ; Handler used to store/retrieve data. ; http://php.net/session.save-handler ;session.save_handler = files session.save_handler = memcache session.save_path="tcp://127.0.0.1:11215?persistent=1"
Это будет значительно быстрее, чем обработчик сеанса по умолчанию на основе файлов
Преимущества использования MySQL в качестве обработчика сеанса состоят в том, что вы можете написать собственный класс, который делает другие вещи, дополнительные вещи, когда данные сохраняются в сеансе. Например, предположим, что вы сохраняете объект, представляющий USER в сеанс. У вас может быть собственный обработчик сеанса для извлечения имени пользователя, идентификатора пользователя, аватара из этого объекта OBJECT и записи их в таблицу MySQL SESSION в свои собственные выделенные столбцы, что позволяет легко показать, кто в сети
Если вам не нужны дополнительные методы в обработчике сеансов, тогда нет причин использовать MySQL для хранения данных сеанса
Приложение PHP теряет информацию о сеансе между запросами. Поскольку у Стэнфорда есть несколько веб-серверов, разные запросы могут быть направлены на разные серверы, а информация о сеансе часто теряется в результате.
Веб-инфраструктура в Стэнфорде состоит из нескольких веб-серверов, которые не разделяют данные сеанса друг с другом. По этой причине сеансы могут быть потеряны между запросами. Использование MySQL эффективно противодействует этой проблеме, поскольку все данные сеанса направлены на сервер базы данных и обратно, а не на веб-кластер. Сохранение сеансов в базе данных также приводит к добавлению конфиденциальности и безопасности, поскольку для доступа к базе данных требуется аутентификация. Мы предлагаем, чтобы все веб-разработчики в Stanford с доступом к MySQL использовали этот метод для обработки сеанса.
Это может вам помочь.
Большинство реализаций сессий стандартных библиотек языков поддерживают только базовую ассоциацию ключей и значений, где ключ предоставляется клиентом (т.е. идентификатор сеанса), и значение хранится на стороне сервера (то есть хранилище сеансов), а затем связано с клиентом запрос.
Все, что помимо этого (особенно меры безопасности), также выходит за рамки этого важного механизма сеанса связи с ключевыми значениями и нуждается в добавлении. Тем более, что эти меры безопасности в основном возникают вместе с ошибками: как определить подлинность запроса определенной сессии? По IP-адресу? По идентификатору агента пользователя? Или оба? Или нет аутентификации сеанса? Это всегда является компромиссом между безопасностью и удобством использования, с которыми разработчик должен справиться.
Но если мне понадобится реализовать обработчик сеанса, я бы просто не искал чистую скорость, но – в зависимости от требований – также для надежности. Memcache может быть быстрым, но если сервер разбился, все данные сеанса теряются. В противоположность этому, база данных более надежна, но может иметь недостатки скорости, противоположные memcache. Но вы не узнаете, пока не проверите и не сравните его по своему усмотрению. Вы даже можете использовать два разных обработчика сеанса, которые обрабатывают разные уровни надежности сеанса ( ненадежны в memcache и надежны в MySQL / файлах).
Но все зависит от ваших требований.
Они оба отличные методы, есть некоторые недостатки в использовании MySQL, которые в некоторых случаях будут уровнями трафика, могут на самом деле привести к краху сервера, если это будет сделано неправильно или загрузка слишком высока!
Я рекомендую лично, учитывая, что стандартные сеансы уже обрабатываются правильно, чтобы просто использовать их и зашифровать данные, которые вы не хотите видеть хакерам.
cookie небезопасно использовать без надлежащей предосторожности. Если вам не понадобится «Запомнить меня», тогда придерживайтесь сеансов! 🙂
РЕДАКТИРОВАТЬ
Не используйте MD5, это плохое шифрование и дешифрование … Я рекомендую засовывать данные и шифровать их все вместе.
$salt = 'dsasda90742308408324708324832'; $password = sha1(sha1(md5('username').md5($salt));
В ближайшее время это шифрование не будет дешифровано, я бы считал это невозможным на данный момент.