Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
Не хочу открывать Америку, но почти 2 недели назад, был создан spark заменяющий стандартный механизм сессий.
мое имхо, топик ни о чем.
мое имхо, топик ни о чем.
На форуме русского сообщества CI, я не видел подобной темы, поэтому мне кажется вы лукавите
Напишите про это поподробнее, или ссылку, если можно.
Вы хоть сами то смотрели чО советуете
сделал ему запрос на пуш в репу двух вещей которые, нашел в первые 5 минут работы с ним. но это не все.
Для тех кому лень смотреть в гите:
1 объявлен пустой метод, то ли для красоты, то ли для создания видимости интерфейса/абстрактного класса. Так вот этот метод и вызывается вместо того который должен.
2 забыта пропертя в классе.
Конгениальная мысль сунуть запись в сессию в дуструктор подразумевает что в этом же деструкторе будет запись в куки, а значит вывод всего прочего контента должен быть еще позже.
сделал ему запрос на пуш в репу двух вещей которые, нашел в первые 5 минут работы с ним. но это не все.
Для тех кому лень смотреть в гите:
1 объявлен пустой метод, то ли для красоты, то ли для создания видимости интерфейса/абстрактного класса. Так вот этот метод и вызывается вместо того который должен.
2 забыта пропертя в классе.
Конгениальная мысль сунуть запись в сессию в дуструктор подразумевает что в этом же деструкторе будет запись в куки, а значит вывод всего прочего контента должен быть еще позже.
1. Я предпочитаю максимально использовать встроенные возможности фреймворка. Костыль не столь страшен, чтоб им брезговать и не требует установки дополнительных навороченных расширений.
2. То, что он его заменяет (а именно дает возможность использовать разные драйверы) не означает, что сами принципы действия изменены. Вы проверяли, делали на этих сессиях длительную авторизацию?
2. То, что он его заменяет (а именно дает возможность использовать разные драйверы) не означает, что сами принципы действия изменены. Вы проверяли, делали на этих сессиях длительную авторизацию?
1. Как раз костыль и страшен +)
2. Да, делал и этот драйвер решает вашу проблему, хоть проблема и надуманная (надуманная потому что, по мимо фреймворка нужно включать мозг и делать правильно).
2. Да, делал и этот драйвер решает вашу проблему, хоть проблема и надуманная (надуманная потому что, по мимо фреймворка нужно включать мозг и делать правильно).
И как, по-вашему, правильно?
Правильно отказаться от CI сессий в пользу библиотек сообщества, например native session
Но это временная мера +) в новой версии фреймворка эту ошибку поправят
В самом начале топика я написал, что считаю единственно верным хранить сессии в базе.
Этому есть масса причин, как с точки зрения безопасности, так и с точки зрения управления работой сайта.
Native session использует встроенные в PHP нативные сессии, которые меня не устраивают.
Встроенные сессии — прекарсны абсолютно во всем, кроме одного-единственного недостатка, который устраняется одним хуком. Легко и просто.
И тем более, если это временная мера, то я смогу обновить фреймворк и убрать этот хук — и все будет продолжать работать точно так же.
Этому есть масса причин, как с точки зрения безопасности, так и с точки зрения управления работой сайта.
Native session использует встроенные в PHP нативные сессии, которые меня не устраивают.
Встроенные сессии — прекарсны абсолютно во всем, кроме одного-единственного недостатка, который устраняется одним хуком. Легко и просто.
И тем более, если это временная мера, то я смогу обновить фреймворк и убрать этот хук — и все будет продолжать работать точно так же.
Спасибо за — всем поставившем, я рад любой реакции
И вот главная проблема в том, что при обновлении сессии меняется session_id и текущая сессия у пользователя сессия прерывается, стартует новая.
Все правильно. Сделано это как дополнительная защита от перехвата сессии. Пользователь продожает работать в системе, но перехваченная сессия уже неактуальна. Проблема — при одноверменном открытии нескольких вкладок может получиться ситаация что запрос пойдет уже по несуществующему session_id (не везде успеет обновиться). И решение тут должно быть другое — не отключать этот механизм, а хранить оба идентификатора сессий (текущий и предыдущий), пускать пользователя тоже по обоим. Время хранения предыдущего идентификатора можно уменьшить до 1 минуты.
А смысл какие-то хуки делать? Вы не можете поместить свой код в __construct() User контроллера?
нефиг стартовать сессию у неавторизованных
И что, что 20 лямов хитов? Проблема-то в чем?
Сессии передергиваются раз в 5 минут, а не при каждом хите.
А если на на сайт каждый день ходит 20 лямов авторизованных пользователей — то это уже вконтакте)) Или даже больше, чем у вконтакте. А это уже совсем другой уровень, распределенные базы и десятки серверов.
Я бы, в таком случае, дляс сессий поднял бы отдельную NoSQL базу — идеальный вариант. Выбирать нужно только по одному ключу, а уж для nosql поиск по 20 лямам записей — плевое дело. (да, по большому счету, и для postgresql это не такая уж и проблема)
Сессии передергиваются раз в 5 минут, а не при каждом хите.
А если на на сайт каждый день ходит 20 лямов авторизованных пользователей — то это уже вконтакте)) Или даже больше, чем у вконтакте. А это уже совсем другой уровень, распределенные базы и десятки серверов.
Я бы, в таком случае, дляс сессий поднял бы отдельную NoSQL базу — идеальный вариант. Выбирать нужно только по одному ключу, а уж для nosql поиск по 20 лямам записей — плевое дело. (да, по большому счету, и для postgresql это не такая уж и проблема)
Как сказал мне один товарищь, очень большой специалист по постгресу (нет, правда, очень крутой): «Когда таблица распухнет до 300 миллионов записей — тогда можно начинать думать, что с ней делать. А до тех пор — можно даже не обращать внимания».
А мускуль в нагруженных проектах я вообще не признаю. PG намного лучше себя показывает под высокими нагрузками. Я понимаю, что ЖЖ на мускуле, что есть memcached и т.п. Но все эти танцы с бубнами по тюнингу мускула против дичайшей отказоустойчивости «из коробки» постгреса, который тоже можно еще оттюнить — я предпочту второе.
И много-петабайтная поисковая база Yahoo (была, пока они на бинг не перешли :(( ) на postgres — тоже весьма показательна.
А что до ваших примеров — то складываете сессии в Redis и держите хоть 20, хоть 200 миллионов хитов. Опять же, на таких нагрузках совсем другой подход к архитектуре и данные нужно распределять по хранилищам в зависимости от условий их использования.
Сессии и var-cache в key-value хранилища вроде Redis.
Какие-то данные (вроде пользователей или каких-нибудь комплексных объектов) в document oriented nosql, вроде Mongo или CouchDB.
А за спиной этого всего стоит основное SQL хранилище в виде postgres или oracle.
Про кассандру не забываем, кстати, тоже, у нее тоже есть стороны, где она особенно сильна.
И по максимуму использовать лучшие стороны всех этих решений.
Возьмите тот же Facebook — там используется всё что может использоваться, для получаения максиальной эффективности от всех технологий.
Но это уже совсем другая парафия.
А для проектов, у которых до несокльких миллионов хитов — sql-решения на том же постгре вполне дееспособны, говорю по собственному опыту. Ниразу еще проблем небыло.
PS
Если что, я ни в коему случае не умаляю ваше мнение, просто обсуждаю)
А мускуль в нагруженных проектах я вообще не признаю. PG намного лучше себя показывает под высокими нагрузками. Я понимаю, что ЖЖ на мускуле, что есть memcached и т.п. Но все эти танцы с бубнами по тюнингу мускула против дичайшей отказоустойчивости «из коробки» постгреса, который тоже можно еще оттюнить — я предпочту второе.
И много-петабайтная поисковая база Yahoo (была, пока они на бинг не перешли :(( ) на postgres — тоже весьма показательна.
А что до ваших примеров — то складываете сессии в Redis и держите хоть 20, хоть 200 миллионов хитов. Опять же, на таких нагрузках совсем другой подход к архитектуре и данные нужно распределять по хранилищам в зависимости от условий их использования.
Сессии и var-cache в key-value хранилища вроде Redis.
Какие-то данные (вроде пользователей или каких-нибудь комплексных объектов) в document oriented nosql, вроде Mongo или CouchDB.
А за спиной этого всего стоит основное SQL хранилище в виде postgres или oracle.
Про кассандру не забываем, кстати, тоже, у нее тоже есть стороны, где она особенно сильна.
И по максимуму использовать лучшие стороны всех этих решений.
Возьмите тот же Facebook — там используется всё что может использоваться, для получаения максиальной эффективности от всех технологий.
Но это уже совсем другая парафия.
А для проектов, у которых до несокльких миллионов хитов — sql-решения на том же постгре вполне дееспособны, говорю по собственному опыту. Ниразу еще проблем небыло.
PS
Если что, я ни в коему случае не умаляю ваше мнение, просто обсуждаю)
не скрою, что мне трудно верить в такую цифру, но предположу, что проблему могли решить NoSQL и Memcached.
Кстати, не знаете, как заставить игнайтер не стартовать сессию всем подряд?)
Какая «сука» минусует все подряд?
А разве нельзя просто написать, чтобы сессия не заканчивалась и не уничтожалась при закрытии браузера?
Или я что-то не так понял?
$config['sess_expiration'] = 0;
$config['sess_expire_on_close'] = FALSE;Или я что-то не так понял?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Codeigniter: делаем сессии наконец стабильными (прежде всего для авторизаций)