LINUX.ORG.RU

вечные сессии

 , , ,


1

2

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

С другой стороны это ресурсо-ёмко и не всегда реализуемо. И тем не менее встречаются сайты с практически вечной авторизацией. Как это реализовать с минимальными нагрузками есть конечно идеи (файлы, указатели, не БД), но хотелось бы узнать Ваше мнение и если есть чем поделиться опыт уважаемые.

Сразу скажу насчет файлов: оно конечно хорошо, но хэшированные каталоги или просто плоский список рано или поздно забъет фс так, что будешь удалять, если повезет 2 часа... Не говорю уже о бекапах.

собственно интересуют Ваше мнение.

Дискасс.

причем тут файлы и указатели вообще не понял

trashymichael ★★★
()
Ответ на: комментарий от trashymichael

возможно, т.к. в поиске идей реализации, просто хотелось бы реализовать практически вечные сессии, но с минимальной нагрузкой на систему

причем тут файлы и указатели вообще не понял

речь идет о серверной части так-же: использовать не БД и мемкэш традиционно, а просто файлы. В файлах хранить указатели на контексты т.к. всегда возможна ситуация, когда нужно перенести сессию на другую ноду например.

swwwfactory ★★
() автор топика

Храни состояние на клиенте в подписанных сервером (зашифрованных, если есть желание) куках. Отвечай, проверив подпись, согласно состоянию. Минимум ресурсов и реализуемо при вменяемой архитектуре.

У тебя какие-то странные знания о БД: типичная БД (не считая тех, где явно указано: не сохраняет на диск вроде memcached/redis) вполне себе ок для хранения сессий. Но когда они хранятся на клиенте — проще и менее ресурсоёмко.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Храни состояние на клиенте в подписанных сервером (зашифрованных, если есть желание) куках. Отвечай, проверив подпись, согласно состоянию. Минимум ресурсов и реализуемо при вменяемой архитектуре.

здесь с этим все ок, хотя да - акцентировать внимание на хранении не на сервере а на клиенте. localStorage в помощь. Но мне надо по возможности еще хранить некоторые серверные данные, что может быть монструозно. В идеале: SID не более. Так-что от зоопарка сидов на сервере не уйти полностью.

У тебя какие-то странные знания о БД: типичная БД (не считая тех, где явно указано: не сохраняет на диск вроде memcached/redis) вполне себе ок для хранения сессий.

на БД, и мемкэшах уже было, потом обеспечивать синхронность, надежность нод, переподнимать это все - хочется странного и понять можно ли без них обойтись (без лишних сущностей), только файлами (много мелких скорее всего). Хотя да: мемкэш вполне на диск выгружается/загружается

swwwfactory ★★
() автор топика

Да храни все в файлах. Просто разбивай их на директории, например, файл ba1f2511fc30423bdbb183fe33f3dd0f храни как ba/1f/25/11/fc30423bdbb183fe33f3dd0f.

heisenberg ★★
()
Ответ на: комментарий от swwwfactory

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

trashymichael ★★★
()
Ответ на: комментарий от trashymichael

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

Благодарю искренне за твою заботу и предостережения конечно, но заметь, не вечные куки, а вечные сессии для удобства самих-же пользователей и по желанию. ЛОР, delicious, diigo.com например и многие другие сайты держат сессию вполне вечно и видимо проклятия так и сыпятся, но по другому поводу и совсем не туда. Мне надо такие сессии, чтобы после рестарта и переноса хоста, у пользователя сессия продолжала работать как ни в чём не бывало. Даже если сессия в БД это в общем известное решение, но стремное. Хочется чего-то простого и надежного.

Однако эта простота выливается в то, что на сервере начнут появляться «вечные файлы» и непонятно как их утилизировать. Точнее неясно - есть там сессия или нет. Отсюда накопление мусора. Идея насчет хранения на клиенте имеет место быть в этом плане...

проблемы с переносом на ноду базы нет

стремно - нода (где БД) отвалилась, если горячей синхронизации нет - привет.

swwwfactory ★★
() автор топика
Ответ на: комментарий от heisenberg

В общем так и делаю, но папки однобуквенные и с уровнем два. Все хорошо, только удаляются долго.

Но эти папки хешированные сильно забивают фс, как уже говорилось, особенно это актуально для вечных сессий. Хотя можно в принципе забить на это... Но мусора не хотелось бы... Еще на забываем о клиентах, ботах не поддерживающих куки...

swwwfactory ★★
() автор топика
Ответ на: комментарий от anonymous

В чём проблема с базой?

с базой в общем более менее ясно, но не хочется схем хост(хосты)-база(базы) Понятно, что горячая репликация как в слоне или nosql (даже диван подойдет, там легко сделать репликацию). Хочется понять, возможно ли более простое решение и без ограничений.

Кстати, насчет уборки мусора, да можно сделать время сессии побольше (с продлением), но в разумных пределах и регулярно проводить зачистку. Но тем не менее - идеально было бы пользователю дать его сессию, если он ломанется не через неделю-месяц.

swwwfactory ★★
() автор топика
Последнее исправление: swwwfactory (всего исправлений: 1)
Ответ на: комментарий от swwwfactory

слушай, мне впадло на тебя тратить время, вечная сессия на лоре это большой expire= для куки, а твое понятие сессии очевидно ограничено сессиями из пхп

trashymichael ★★★
()
Ответ на: комментарий от trashymichael

Извини конечно, дружище не хотел тебя задеть чем-то. Что совсем заработался?

твое понятие сессии очевидно ограничено сессиями из пхп

по себе не стоит судить, да и вообще...

swwwfactory ★★
() автор топика
Ответ на: комментарий от trashymichael

сделай вид что я не писал в этот топик, ок?

слушаю и повинуюсь

swwwfactory ★★
() автор топика
Ответ на: комментарий от swwwfactory

не вечные куки, а вечные сессии для удобства самих-же пользователей и по желанию

В чем отличие и что ты понимаешь под «сессией»?

Мне надо такие сессии, чтобы после рестарта и переноса хоста, у пользователя сессия продолжала работать как ни в чём не бывало.

PHP головного мозга.

edigaryev ★★★★★
()
Ответ на: комментарий от edigaryev

если дельное что есть, высказывайся.

Куки, всего лишь частный случай в цепочке организации сеанса взаимодействия как правило клиент-сервер. Но речь собственно больше идет об оптимальной схеме хранения и утилизации сессионных данных на сервере или (возможно) комбинированным способом.

Перенос и восстановление сессий можно организовать по разному. Причем тут PHP? Все схемы (и возможности), за исключением, наверное эрланга примерно одинаковы.

swwwfactory ★★
() автор топика
Ответ на: комментарий от swwwfactory

Но речь собственно больше идет об оптимальной схеме хранения и утилизации сессионных данных на сервере или (возможно) комбинированным способом.

Для простейшей аутентификации пользователя на каждой странице сайта (чтобы не нужно было вводить пароль каждый раз) достаточно хранить уникальный токен в БД (например, используя отдельное поле в записи определенного пользователя) и соответственно у пользователя при помощи Cookies.

Перенос и восстановление сессий можно организовать по разному.

Ты так и не объяснил, что ты понимаешь под сессиями.

edigaryev ★★★★★
()
Ответ на: комментарий от edigaryev

Ты так и не объяснил, что ты понимаешь под сессиями.

если спрашиваю про оптимальное хранение сессионных данных, наверное есть понимание и были разные схемы реализаций (в основном БД+сиды в урлах или куки, кое-что еще другое). Привязка сеансовых данных к некоему контексту, например фильтр яндекс-маркета (хотя там в урлах вроде хранится, что не совсем гуд) достаточно?

Вариант с БД понятен и прост, соответственно не очень интересен, даже c nosql.

С мемкэшем/редисом примерно тоже самое.

Есть здравый смысл в хранении сессионных данных на клиенте, но нагружать канал не хочется, хотя есть localStorage как говорилось выше, но необходимость как-то представляться в куках остается, например если с сессией связан постоянный коннект с БД.

swwwfactory ★★
() автор топика
Последнее исправление: swwwfactory (всего исправлений: 1)
Ответ на: комментарий от swwwfactory

Все зависит от того, что за данные ты собираешься хранить.

Например, в твоем примере с Яндекс.Маркетом я бы не сказал что это однозначно плохо, потому-что подобный подход может быть очень удобен — пользователю достаточно скопировать ссылку и передать её другому пользователю, чтобы тот увидел то же самое, что и первый (выбранные фильтры, etc.).

edigaryev ★★★★★
()
Ответ на: комментарий от edigaryev

Все зависит от того, что за данные ты собираешься хранить.

Хотелось бы не заморачиваться с этим и не привязываться к этому т.к. данные могут быть довольно вариативны, но если это сериализуется так или иначе или «портабельно» по определению (текст, скалярные данные), то сойдет.

Например, в твоем примере с Яндекс.Маркетом я бы не сказал что это однозначно плохо, потому-что подобный подход может быть очень удобен — пользователю достаточно скопировать ссылку и передать её другому пользователю, чтобы тот увидел то же самое, что и первый (выбранные фильтры, etc.).

Да, это удобно, согласен (но небезопасно и сложно в реализации). Не совсем показательный пример, но актуальный, когда надо расшарить урл. Собственно там нет сессии как таковой с точки зрения хранения контекста фильтра пользователя. Но небольшая порция сессионных данных хранится в урле. Практически это вырожденный случай сессий - как бы сессия, но не совсем. Контроллер логики страницы в основном берет информацию с урла, но такое не всегда удобно и возможно, поэтому классическое связывание проиcходит через SID.

swwwfactory ★★
() автор топика
Ответ на: комментарий от swwwfactory

Все зависит от того, что за данные ты собираешься хранить.

Хотелось бы не заморачиваться с этим и не привязываться к этому

В таком случае предлагаю не заморачиваться и с мыслью о том, где и как эти данные хранить.

edigaryev ★★★★★
()
Ответ на: комментарий от edigaryev

В таком случае предлагаю не заморачиваться и с мыслью о том, где и как эти данные хранить.

т.е. ты предлагаешь ограничиться классической схемой: БД, мемкэш если мы говорим об оптимальной организации хранения сессионных данных (для вечных сессий) на сервере.

swwwfactory ★★
() автор топика
Последнее исправление: swwwfactory (всего исправлений: 1)

Не нужно хранить в сессии, сохраняй в куках нужные для аутентификации данные, закрытые каким-нибудь криптографически стойким методом.

maxcom ★★★★★
()
Ответ на: комментарий от maxcom

Не нужно хранить в сессии, сохраняй в куках нужные для аутентификации данные, закрытые каким-нибудь криптографически стойким методом.

достаточно ведь SID-а, хотя да, можно запихнуть туда данные доступа. Но как-то не очень хочется, даже в криптованном виде держать данные аутентификации фактически на клиенте. Лучше указатель тогда-уж.

Не нужно хранить в сессии

С радостью, но есть ряд данных, типа некоторые состояния, которые нужно хранить, и они ближе к серверу, нежели к браузеру. Проблемы нет куда-то их записать. Проблема в том, что неизвестно когда сессия закончится, если речь идет о практически вечных сессиях. Да, согласен вечная сессия возможна, если ограничится только хранением данных аутентификации. С остальным остается неопределенность.

swwwfactory ★★
() автор топика
Ответ на: комментарий от maxcom

акрытые каким-нибудь криптографически стойким методом.

ой, да ладно тебе :). любой из: md5, sha1, uuid. да хоть тупой рандом из 8-20 символов... тут беда другая, у парня проблема в понимании сути, как оно работает ибо формулировка вопроса однозначно указывает на это.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.