Pull to refresh

Comments 38

Не хочу открывать Америку, но почти 2 недели назад, был создан spark заменяющий стандартный механизм сессий.
мое имхо, топик ни о чем.
На форуме русского сообщества CI, я не видел подобной темы, поэтому мне кажется вы лукавите
Я в основном ищу по англоязычным ресурсам
Напишите про это поподробнее, или ссылку, если можно.
Вы хоть сами то смотрели чО советуете

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

Для тех кому лень смотреть в гите:
1 объявлен пустой метод, то ли для красоты, то ли для создания видимости интерфейса/абстрактного класса. Так вот этот метод и вызывается вместо того который должен.
2 забыта пропертя в классе.

Конгениальная мысль сунуть запись в сессию в дуструктор подразумевает что в этом же деструкторе будет запись в куки, а значит вывод всего прочего контента должен быть еще позже.
1. Я предпочитаю максимально использовать встроенные возможности фреймворка. Костыль не столь страшен, чтоб им брезговать и не требует установки дополнительных навороченных расширений.
2. То, что он его заменяет (а именно дает возможность использовать разные драйверы) не означает, что сами принципы действия изменены. Вы проверяли, делали на этих сессиях длительную авторизацию?
1. Как раз костыль и страшен +)
2. Да, делал и этот драйвер решает вашу проблему, хоть проблема и надуманная (надуманная потому что, по мимо фреймворка нужно включать мозг и делать правильно).
Правильно отказаться от CI сессий в пользу библиотек сообщества, например native session
Но это временная мера +) в новой версии фреймворка эту ошибку поправят
В самом начале топика я написал, что считаю единственно верным хранить сессии в базе.
Этому есть масса причин, как с точки зрения безопасности, так и с точки зрения управления работой сайта.
Native session использует встроенные в PHP нативные сессии, которые меня не устраивают.

Встроенные сессии — прекарсны абсолютно во всем, кроме одного-единственного недостатка, который устраняется одним хуком. Легко и просто.

И тем более, если это временная мера, то я смогу обновить фреймворк и убрать этот хук — и все будет продолжать работать точно так же.
* Во втором абзаце имелись ввиду встроенные в Codeigniter сессии
Встроенные сессии — прекарсны абсолютно во всем, кроме одного-единственного недостатка, который устраняется одним хуком. Легко и просто.

Они говно +) все уже это поняли.
Хранить сессии в базе имеет место быть, но сколько сессий ваша база выдержит?+)
Спасибо за — всем поставившем, я рад любой реакции
И вот главная проблема в том, что при обновлении сессии меняется session_id и текущая сессия у пользователя сессия прерывается, стартует новая.

Все правильно. Сделано это как дополнительная защита от перехвата сессии. Пользователь продожает работать в системе, но перехваченная сессия уже неактуальна. Проблема — при одноверменном открытии нескольких вкладок может получиться ситаация что запрос пойдет уже по несуществующему session_id (не везде успеет обновиться). И решение тут должно быть другое — не отключать этот механизм, а хранить оба идентификатора сессий (текущий и предыдущий), пускать пользователя тоже по обоим. Время хранения предыдущего идентификатора можно уменьшить до 1 минуты.
Правильно оно было бы, если бы при смене session_id не терялись бы данные. А они теряются.
В этом-то и проблема, собственно
Данные не должны теряться. Если так — то баг/недоработка
Вот и я думаю, что не должны)) От чего пришлось костыль придумывать, который описан в заметке)
Говорят, в следующем релизе игнайтера этот баг/недоработку поправят
А смысл какие-то хуки делать? Вы не можете поместить свой код в __construct() User контроллера?
user контроллер — это вы что имеете ввиду?
Спасибо, капитан)
Контроллер в терминологии кодигнайтера — страница/набор страниц.
Если вы это и имели ввиду — то вопрос: а часто вы в свой профиль заглядываете?
CodeIgniter — это фреймворк с MVC парадигмой, поэтому контроллер там — это контроллер.
В профиль — редко.
UFO just landed and posted this here
нефиг стартовать сессию у неавторизованных
UFO just landed and posted this here
И что, что 20 лямов хитов? Проблема-то в чем?
Сессии передергиваются раз в 5 минут, а не при каждом хите.
А если на на сайт каждый день ходит 20 лямов авторизованных пользователей — то это уже вконтакте)) Или даже больше, чем у вконтакте. А это уже совсем другой уровень, распределенные базы и десятки серверов.
Я бы, в таком случае, дляс сессий поднял бы отдельную NoSQL базу — идеальный вариант. Выбирать нужно только по одному ключу, а уж для nosql поиск по 20 лямам записей — плевое дело. (да, по большому счету, и для postgresql это не такая уж и проблема)
UFO just landed and posted this here
Как сказал мне один товарищь, очень большой специалист по постгресу (нет, правда, очень крутой): «Когда таблица распухнет до 300 миллионов записей — тогда можно начинать думать, что с ней делать. А до тех пор — можно даже не обращать внимания».

А мускуль в нагруженных проектах я вообще не признаю. PG намного лучше себя показывает под высокими нагрузками. Я понимаю, что ЖЖ на мускуле, что есть memcached и т.п. Но все эти танцы с бубнами по тюнингу мускула против дичайшей отказоустойчивости «из коробки» постгреса, который тоже можно еще оттюнить — я предпочту второе.
И много-петабайтная поисковая база Yahoo (была, пока они на бинг не перешли :(( ) на postgres — тоже весьма показательна.

А что до ваших примеров — то складываете сессии в Redis и держите хоть 20, хоть 200 миллионов хитов. Опять же, на таких нагрузках совсем другой подход к архитектуре и данные нужно распределять по хранилищам в зависимости от условий их использования.

Сессии и var-cache в key-value хранилища вроде Redis.
Какие-то данные (вроде пользователей или каких-нибудь комплексных объектов) в document oriented nosql, вроде Mongo или CouchDB.
А за спиной этого всего стоит основное SQL хранилище в виде postgres или oracle.
Про кассандру не забываем, кстати, тоже, у нее тоже есть стороны, где она особенно сильна.
И по максимуму использовать лучшие стороны всех этих решений.
Возьмите тот же Facebook — там используется всё что может использоваться, для получаения максиальной эффективности от всех технологий.

Но это уже совсем другая парафия.
А для проектов, у которых до несокльких миллионов хитов — sql-решения на том же постгре вполне дееспособны, говорю по собственному опыту. Ниразу еще проблем небыло.

PS
Если что, я ни в коему случае не умаляю ваше мнение, просто обсуждаю)
UFO just landed and posted this here
не скрою, что мне трудно верить в такую цифру, но предположу, что проблему могли решить NoSQL и Memcached.
UFO just landed and posted this here
Кстати, не знаете, как заставить игнайтер не стартовать сессию всем подряд?)
подгружайте модуль в User controller начиная с формы авторизации
А разве нельзя просто написать, чтобы сессия не заканчивалась и не уничтожалась при закрытии браузера?

$config['sess_expiration'] = 0;
$config['sess_expire_on_close'] = FALSE;

Или я что-то не так понял?
Не так поняли.
Во-первых, совсем вечные сессии имхо зло.
Во-вторых проблема в обновлении session_id при котором теряются сессионные данные.
Не знаю, перечитайте пост, там по-моему достаточно подробно объяснена суть проблемы
Sign up to leave a comment.

Articles