Создание собственного обработчика PHP Session?

Question

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

1. Помимо фиксации сеанса и перехвата сеанса, какие еще проблемы возникают при использовании собственного кода обработки сеансов PHP? Обе эти проблемы легко исправить, но я все еще вижу, как люди пишут свои собственные системы для обработки сессий, поэтому мне интересно, почему.

2. Будет ли обработчик сеансов на основе MySQL быстрее, чем собственные сеансы PHP? Предполагая стандартную (не «память») таблицу.

3. Есть ли какие-либо серьезные недостатки в использовании session_set_save_handler? Я могу сделать так, чтобы он соответствовал моим стандартам по большей части (кроме именования). Плюс мне лично нравится идея использования $_SESSION['blah'] = 'blah' против $session->assign('blah', 'blah') или чего-то в этом роде.

4. Есть ли какие-нибудь хорошие сеансовые ресурсы php, на которые мне стоит взглянуть? В последний раз я работал с сессиями 10 лет назад, поэтому мои знания немного застоялись. Поиски в Google и Stackoverflow приводят ко многим базовым, явно плохо написанным учебным пособиям и примерам (сохраните имя пользователя + md5 (пароль) в cookie, а затем создайте сеанс!), Поэтому я надеюсь, что у кого-то здесь есть какие-то законные ресурсы с большим количеством просмотров.

5. Независимо от моего выбора, я буду вынужден использовать только файлы cookie. Это неправильно в любом случае? Сайты, на которых будет работать этот код, имеют обычных пользователей в средней среде безопасности. Я помню, что это была огромная проблема в последний раз, когда я использовал сеансы, но идея использования сеансов in-url заставляет меня сильно нервничать.

Answer 1

Ответ на 2) - идентификатор зависит.Позвольте мне объяснить: для того, чтобы обработчик сеанса функционировал должным образом, вы действительно должны реализовать некоторый тип механизма блокировки и разблокировки.В MySQL удобно иметь функции блокировки таблицы и разблокировки таблицы.Если вы не реализуете блокировку таблицы в обработчике сеанса, то вы рискуете получить условия гонки в запросах на основе ajax.Поверьте, вы не хотите этого.

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

Хорошо, тогда, если вы добавите LOCK TABLE иРазблокируйте 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 в качестве обработчика сеанса состоят в том, что вы можете написать собственный класс, который выполняет другие действия, дополнительные действия, когда данные сохраняются в сеансе.Например, допустим, вы сохранили объект, который представляет пользователя в сеансе.Вы можете иметь собственный обработчик сеанса для извлечения имени пользователя, идентификатора пользователя, аватара из этого ОБЪЕКТА и записи их в таблицу MySQL SESSION в свои собственные выделенные столбцы, что позволяет легко отображать Кто в сети

Если вам не нужны дополнительные методы в обработчике сеанса, то нет смысла использовать MySQL для хранения данных сеанса

Answer 2

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

Все, что выходит за рамки этого (особенно меры безопасности), также выходит за рамки этого существенного механизма сеанса связи ключ-значение и нуждается в добавлении. Тем более, что эти меры безопасности в основном сопровождаются ошибками: как определить подлинность запроса определенного сеанса? По IP адресу? По идентификации агента пользователя? Или оба? Или нет аутентификации сессии вообще? Это всегда компромисс между безопасностью и удобством использования, с которым разработчик должен иметь дело.

Но если бы мне нужно было реализовать обработчик сеанса, я бы не просто искал чистую скорость, но - в зависимости от требований - также и надежность. Memcache может быть быстрым, но в случае сбоя сервера все данные сеанса теряются. В противоположность этому, база данных более надежна, но может иметь отрицательные стороны скорости, в отличие от memcache. Но вы не узнаете, пока не протестируете и не протестируете его самостоятельно. Вы даже можете использовать два разных обработчика сеанса, которые обрабатывают разные уровни надежности сеанса ( ненадежно в memcache и надежно в MySQL / файлах).

Но все зависит от ваших требований.

Answer 3

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

Веб-инфраструктура в Стэнфорде состоит из нескольких веб-серверов, которые не обмениваются данными сеанса с каждымДругой.По этой причине сеансы могут быть потеряны между запросами.Использование MySQL эффективно противодействует этой проблеме, поскольку все данные сеанса направляются на сервер базы данных и обратно, а не в веб-кластер.Хранение сеансов в базе данных также обеспечивает дополнительную конфиденциальность и безопасность, поскольку доступ к базе данных требует аутентификации.Мы предлагаем всем веб-разработчикам в Стэнфорде, имеющим доступ к MySQL, использовать этот метод для обработки сеансов.

По ссылке http://www.stanford.edu/dept/its/communications/webservices/wiki/index.php/How_to_use_MySQL-based_sessions

Это может помочь вам.

Answer 4

Оба эти метода хороши, есть некоторые недостатки использования MySQL, которые в некоторых случаях могут привести к сбоям в работе сервера, если он будет выполнен неправильно или загрузка слишком высока!

Я рекомендую личночто стандартные сеансы уже обрабатываются должным образом, чтобы просто использовать их и зашифровать данные, которые вы не хотите, чтобы хакеры видели.Если вам не нужно «Запомнить меня», то придерживайтесь сессий!:)

РЕДАКТИРОВАТЬ

Не использовать MD5, это плохое шифрование и расшифровка ... Я рекомендую солить данные и шифровать их все вместе.

$salt = 'dsasda90742308408324708324832';
$password = sha1(sha1(md5('username').md5($salt));

Это шифрование не будет расшифровано в ближайшее время, я бы посчитал это невозможным на данный момент.