Использовать сессии для экономии одного запроса в базу - так себе агрумент. Во-первых, такой подход создает еще кучу неудобств по управлению пользователем со стороны администратора - попробуй, удали оперативно такого пользователя - придется еще его сессию искать, а что бы его сессию искать - придется еще ее ключ в той же базе хранить. Во-вторых, заявления, что файлы работают быстрее базы - не состоятельны, зависит от огромного числа факторов. В-третьих, рано или поздно придется (точно говорю =) убрать сессии в базу, и тут первый аргумент вообще выпадает.
Угон кук из той же серии - страшилка, с непониманием сути. Если вы делаете так называемый "автологин", то угонят ключ автологина, и пофиг на то, что ключ сессии живет 5 часов. С другой стороны, если начать думать, то понимаешь, что в ключ сессии можно подмешивать любую информацию. Юзерагент, нужное число окетов IP адреса, интервал времени, пока этот ключ валиден. Т.е. короткая сессия не защищает от "угона", если используется автологин, если же автологин не используется, время жизни можно ограничить и без сессии.
Нет, ключи я в базе не храню, вы не поняли. Ключ является итогом хеширования набора доступной программисту информации, его не нужно хранить вообще, ибо его можно опять сгенерировать на стороне сервера и сравнить с тем, что пришло. Как бонус получаете очень полезную функцию сброса "автологина" на всех компьютерах при изменении пароля - хеш пароля меняется = все ключи невалидны.
Csrf точно так же можно генерить от неких данных - банально от user_id, IP и т.д.
Понимаете, сессии - это механизм создания приложений начального уровня. Он удобен тем, что уже есть, что прост в использовании и программисту вообще не нужно ни о чем думать. Как только вы собираетесь делать сложное приложение, сессии начинают мешать. Начинается нагромождение костылей - куда сессии класть, как их чистить и т.д. и т.п. - и в итоге получается подобие того, что сделали бы изначально сами (а именно - пересистент в базе + кеширование и короткоживущее в мемкеше), только гораздо менее гибко и прозрачно - вы ограничены одним местом хранения, и не можете разбросать данные по разным, не можете назначить данным разное время жизни и т.п. Т.е. можете, конечно, но продолжением костылей.
ЗЫ И проблем в поддержке не вижу. А вот проблемы в поддержке толпы файлов на диске - вполне вижу. Но вообще-то если вы не видите преимуществ отказа от сессий - не отказывайтесь. В конце концов, мало кто умеет использовать чужой грабельный опыт.
Как лучше подойти к этому вопросу, можно хранить на файлах или лучше перенести в память типа memcache, redis и т.п.? В память не особо желательно двигать это все так как будут много операций в памяти и хранить не основные stateful значения не особо хочется. Если хранить на файлах то будут ли тормоза в таком количество когда будет срабатывать gc? И вообще будут ли тормоза если скажем сессии в размере например 50к хранятся на файлах?
