Сессия не работает из-за session_regenerate_id на версиях PHP выше 5_3?

вопрос

Так как блог не работает, я хотел сообщить всем, что Вход (у меня версия DLE 10,2) не работает правильным образом на версиях выше 5,3. В админке моего хостинга долгое время была надпись 5,3 (рекомендуется, стабильная версия). Но потом я заметил, что уже пишет PHP 5.6 (рекомендуется, стабильная версия). Соответственно я поменял и очень долгое время ничего не подозревал. На моем сайте работал вход. Я все протестировал и успокоился. Но проблема глубже.

Когда мы делаем первый вход, то сначала проверка происходит через базу данных:
после вот этого места

elseif( isset( $_COOKIE['dle_user_id'] ) AND intval( $_COOKIE['dle_user_id'] ) > 0 AND $_COOKIE['dle_password']){

в этом условии есть такие строчки:

			$_SESSION['dle_user_id'] = $member_id['user_id'];
			$_SESSION['dle_password'] = $_COOKIE['dle_password'];
			$_SESSION['member_lasttime'] = $member_id['lastdate'];

а перед эти строчками есть функция, которая должна была генерировать и обновлять идентификатор текущей сессии:

[b]session_regenerate_id()[/b];

и вот в новых версиях, наличия этой строчки предвещает беду. Я ее просто закомментировал и все заработало как надо.

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

И еще один совет, кто не может перейти с старых версий на новую через многочисленные правки или другие причины. В запросах SELECT к базе данных команда разработчиков DLE не использовала самое главное! Они опустили важный момент LIMIT 1. Я лично проводил тесты с наличием LIMIT 1 и без него и могу точно сообщить, что скорость выполнения запроса к MySQL может быть увеличена в СТО РАЗ если эта запись практически первая и база данных большая и примерно на пару миллисекунд быстрее, если это последняя запись.Если LIMIT не поставить, то поиск продолжается до самого конца. По этому и тратится дорогое время. А теперь посчитайте, если у вас много пользователей и много новостей. LIMIT 1 очень быстрей справляется с заданием.

Это был не вопрос, но все же интересно будет узнать что другие думают и было ли полезно.

Ответа пока нет

3 комментария

PHP-developer

2583

vitnet - 2017-09-0329 октября 2017 16:19 - #65948

О каком лимите идет речь и зачем он вообще нужен если выбор идет по конкретному значению?

Нужен LIMIT

SELECT * FROM " . USERPREFIX . "_users WHERE (`user_id` LIKE '%" . intval($_SESSION['dle_user_id']) . "%') LIMIT 1

Не нужен LIMIT

SELECT * FROM " . USERPREFIX . "_users WHERE user_id='" . intval($_SESSION['dle_user_id']) . "'

Юзер

andriy159 - 2017-09-0329 октября 2017 16:27 - #65952

не согласен
Версия 10.2 (не знаю как дальше) не имеет никаких LIMIT кроме случев когда мы смотрим ОТ и ДО (диапазон)
Если проверять читать один пост да и еще он не последний в списке базы данных, то вот результат

Отображение строк 0 - 0 (1 всего, Запрос занял 0.0253 сек.)
SELECT * FROM `partner_post` WHERE id=135

Отображение строк 0 - 0 (1 всего, Запрос занял 0.0119 сек.)
SELECT * FROM `partner_post` WHERE id=135 LIMIT 1

Эксперт

1925

nowheremany - 2017-09-0330 октября 2017 09:40 - #65969

Вы не правильно тестируете ) Почему с LIMIT скорость выполнения запроса меньше - тут вариантов может множество и он не связан с LIMIT.

Анализировать скорость выполнения запроса можно только через EXPLAIN SELECT ...

Например:

explain select * from dle_users where user_id = 1;
explain select * from dle_users where user_id = 1 limit 1;

В ответе в колонке rows будет показано сколько строк в базе просмотрено. В запросе 1 строка - по тому что user_id - индекс PRIMARY KEY.
В вашем запросе скорее всего просматриваются все записи таблицы из-за этого большое время выполнение - причем вы забываете про кэш запросов движка MySQL - так что это не показатель.

Благодарность принимаю тут Связь