Смотрю, к разговору совсем наркоманы подключаются. Результат аутентификации и есть идентификатор пользователя, а вы занимаете совершенно бессмысленными с точки зрения информационной безопасности экстраполяциями.
Не каждую, не думайте за меня плиз. Кроме того, я считаю, что сессия и есть идеальное хранилище для идентификатора пользователя.
2VolCh: Пользователь не должен знать ничего о том, как он представлен внутри системы управления сайтом, в том числе не должен знать свой айди. Для меня это настолько очевидно, что я даже не знаю, как это понятно аргументировать. Ну, например, это уже осложняет некоторые SQL-инъекции как минимум.
Ну вы советуете завести под id пользователя видимо какое-то отдельное хранилище. Я говорю, что это Бритва Оккама, и давайте же в это хранилище и остальные данные пихать, и назовем его сессия, и не будем его экспайрить.
Да это потому что я комментировать только раз в пять минут умею.
Суть токова.
Чтобы закончить с инвалидацией — зря удивляетесь, потому что это не инвалидация на самом деле (как считаете вы) а именно дропание. Инвалидация, это когда на место дропнутого кэша генерируется новый, а на этот случай дерево блоков как раз и позволяет сэкономить ресурсы и не генерировать новые блоки того, что не изменилось. А вручную, это как-то так: cache::drop('catalog') или cache::drop_by_tag('product_1').
Насчет вечноживущих сессий я честно не знаю, чего вы добиваетесь, ведь я же уже несколько раз сказал: данные, которые нельзя светить в бд/где угодно, где их можно легко найти, но нужно хранить и использовать. Пример, кстати, вы привели сами в самом начале: идентификатор текущего пользователя. Аргумент: пользователь, кем бы он ни был, не должен знать своего идентификатора. Тем более иметь возможность подменить его в куке.
Э. Вообще-то у SSD дисков (во всяком случае, мне такой экземпляр наверное попался) время случайного и последовательного доступа никак друг от друга не отличаются. RAID контролеры тоже частично снимают эту проблему. Допускаю, что в целом время доступа к памяти и к контролеру SATA могут отличаться в пользу памяти, но не думаю, что разница настолько огромная, чтобы на нее так дрочить. Ну и эцсамое, жрите поменьше, кэш магазина на 1000 товаров занимает… ну, гигабайта два наверное.
Кстати, такая инвалидация происходит ведь при изменении данных, это случается в десятки раз реже, чем просмотр. Что касается о_О, то вы пропустили мой пассаж про ассоциативное дерево, а теперь чему-то удивляетесь.
Пока отдельного камня нет, я за кэш прямо сейчас скажу вот что: если его просто дропать в нужные моменты, и хранить с ассоциативным графом при этом, и не хранить в кэше вечно то, что может засорить в будущем диск — с современными объемами хардов проблема не такая уж и большая. Я, во всяком случае, пока отлично обхожусь без инвалидации.
Бывают такие куки, которые сложно потерять. Да и синхронизация не такая большая проблема в вероятном будущем. Касаемо ресурсов, то это проблему можно решить отдельным камнем на ssd-диске, которые будет заниматься только инвалидацией. Ну, знаете там, хранить карту, следить за atime и size, вот это все.
Я отвечу еще раз не зачем, а почему. Потому что в хранящихся ограниченное время сессиях есть небольшая проблема. Дело в том, что разные данные имеют тенденцию протухать с разной скоростью, так что например приведенный вами пример длинной формы может храниться несколько дней, а упомянутый опять же вами токен csrf может испортиться и через несколько секунд. Приводить весь этот огород к одному универсальному числу не имеет никакого смысла.
К тому же, в вечных сессиях очень прикольно хранить такие штуки, как все ай пи адреса, с которых заходил пользователь, или еще какие-то данные, которые должны быть спрятаны от всех, включая разработчиков, и доступны только для какого-либо анализа.
Не в год, а в вечность, хе-хе:)
Ну поймите же, у сессии в идеале вообще не должно быть экспайра. Экспайр может быть у кэша (хотя и там он совсем не обязателен, по крайней мере в идеале для кэша лайфтайм должен быть по умолчанию тоже вечностью, если явно не указано другое), но поскольку у нас нет квантовых хранилищ информации, нужно как то стирать случайных посетителей. В то же время, если человек выбирает «ЗАПОМНИТЬ меня», приборчик обязан его, черт побери, запоминать! В самом деле, вы же за забудете человека, если один раз запомните его? А веб-сайты это постоянно делают, сплошная ложь кругом.
Ох. Я вам говорю — каждому-свое, и в сессии не должно быть кэша, а вы мне отвечаете: ну, «нам» нужно обязательно запихнуть в сессию «данные, которые могут протухнуть» (хотя это и есть вольное определение слова «кэш») и гнете таким образом свою линию. Ок, продолжайте.
Но для этого (как и для кэша) должно быть реализовано отдельное специализированное хранилище.
В сессии хранятся (должны хранится) как раз те данные, которые не потеряют актуальность, даже если пользователь впал в кому или на телефоне закончились деньги. Например, адрес, который пользователь ввел в форму заказа, а потом решил нажать назад, чтобы посмотреть что-нибудь еще. Или идентификатор самого пользователя. Или личные предпочтения (но вообще для них тоже должно быть создано более идеальное хранилище).
Не вижу абсолютно никаких проблем в вечно хранящемся списке посещенных страниц (еще желательно с таймстампами и прочими полезными данными). Думаю, разработчики поисковых гигантов и рекламных систем меня поддержат.
2VolCh: Пользователь не должен знать ничего о том, как он представлен внутри системы управления сайтом, в том числе не должен знать свой айди. Для меня это настолько очевидно, что я даже не знаю, как это понятно аргументировать. Ну, например, это уже осложняет некоторые SQL-инъекции как минимум.
> Я и не говорил, что в куках будет id пользователя.
Бритва?
Суть токова.
Чтобы закончить с инвалидацией — зря удивляетесь, потому что это не инвалидация на самом деле (как считаете вы) а именно дропание. Инвалидация, это когда на место дропнутого кэша генерируется новый, а на этот случай дерево блоков как раз и позволяет сэкономить ресурсы и не генерировать новые блоки того, что не изменилось. А вручную, это как-то так: cache::drop('catalog') или cache::drop_by_tag('product_1').
Насчет вечноживущих сессий я честно не знаю, чего вы добиваетесь, ведь я же уже несколько раз сказал: данные, которые нельзя светить в бд/где угодно, где их можно легко найти, но нужно хранить и использовать. Пример, кстати, вы привели сами в самом начале: идентификатор текущего пользователя. Аргумент: пользователь, кем бы он ни был, не должен знать своего идентификатора. Тем более иметь возможность подменить его в куке.
Кстати, такая инвалидация происходит ведь при изменении данных, это случается в десятки раз реже, чем просмотр. Что касается о_О, то вы пропустили мой пассаж про ассоциативное дерево, а теперь чему-то удивляетесь.
К тому же, в вечных сессиях очень прикольно хранить такие штуки, как все ай пи адреса, с которых заходил пользователь, или еще какие-то данные, которые должны быть спрятаны от всех, включая разработчиков, и доступны только для какого-либо анализа.
Ну поймите же, у сессии в идеале вообще не должно быть экспайра. Экспайр может быть у кэша (хотя и там он совсем не обязателен, по крайней мере в идеале для кэша лайфтайм должен быть по умолчанию тоже вечностью, если явно не указано другое), но поскольку у нас нет квантовых хранилищ информации, нужно как то стирать случайных посетителей. В то же время, если человек выбирает «ЗАПОМНИТЬ меня», приборчик обязан его, черт побери, запоминать! В самом деле, вы же за забудете человека, если один раз запомните его? А веб-сайты это постоянно делают, сплошная ложь кругом.
В сессии хранятся (должны хранится) как раз те данные, которые не потеряют актуальность, даже если пользователь впал в кому или на телефоне закончились деньги. Например, адрес, который пользователь ввел в форму заказа, а потом решил нажать назад, чтобы посмотреть что-нибудь еще. Или идентификатор самого пользователя. Или личные предпочтения (но вообще для них тоже должно быть создано более идеальное хранилище).