Или я тупой или погода такая... Объясни мне, пожалуйста, как ты достанешь из md5 хеша ID.




Если ты используешь некий секрет кей для автологина (в коем я вообще необходимости практически не вижу), на кой фиг в куку еще и ID юзера писать?

из md5 хеша id никак не достать, никто этого делать и не будет

будут тупо брать id от 1-100000, делаем md5 хеш по этому id

отстается сравнить наш кеш с хешем в системе.

В случае md5(id + time())  - несложится. Разве что time() всегда будет одинаковым, но тогда это называется salt 

Да не md5 от ID хранить в куке, а просто ID, число. И плевать, что его можно изменить, все равно это ничего не даст злоумышленнику.


Затем, что проще достать пользователя по pk из кеша, чем нагружать дополнительным запросом БД + создавать дополнительный индекс по очень часто изменяемому полю размером в целых 32 байта.


В таком случае я бы хотел услышать вашу реализацию автологина.

О боже, какие сложности для реализации столь простой вещи.



http://php.net/manual/en/function.session-...okie-params.php
И, если честно, совершенно не вижу разницы между неким secret key и id сессии.

Что касается "проще достать пользователя по pk из кеша", тут я совершенно несогласен. Во первых - кэш служит в качестве промежуточного буфера и чаще всего имеет ограничения на размер и срок жизни. Изобретение собственного механизма с сроком хранения равным сроку жизни автологина - абсурд. Впрочем, даже если и так - это можно сделать с помощью одной простой настройки стандартных сессий в PHP.

Большинстве middle-load проектов обходятся обычными сессиями под БД и в производительности от этого не страдают. Что касается категории пониже, имхо - им достаточно обычного механизма сессий.

В контексте high-load все слишком сильно зависит от используемой платформы, архитектуры проекта и конкретных задач.

Куда уж проще достать юзера по pk?


Т.е. вы предлагаете держать сессию месяцами, а то и вечно? При этом отключив полностью GC и, по сути, не меняя на протяжении всего времени ее ID? Я правильно понял?


Что за ерунду вы несете? Вы не знаете как работает кеш? Если запись есть в кеше, она возвращается, если нету, делается запрос к БД (по тому же pk) и запись кладется в кеш. И не надо никакого "собственного механизма", имелся ввиду обычный общий кеш пользователей, который и так дергается ежесекундно.

Этот простой алгоритм одинаково хорошо работает в любых категория проекта и не зависит от backend'а механизма сессий.

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


Я предлагаю вариант без лищних прослоек. Моя сессия как и ваш pk за месяц, что пользователь не заходил на сайт, не изменится. А уж сделать регенерацию идентификатора сессии после автологина Вам точно никто не запрещает.

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



Уж поверьте, я знаю о кешировании не меньше вашего, а то и больше. И, в данном случае, в связи с Вашим последним заявлением, я вижу всю бессмысленность предыдущего поста:


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



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

— а ты знаешь вообще КАК ведёт себя оператор "+" если один операнд — string, а другой — integer?

Ну расскажи!

Ох, написали-то. 
1 Сервер - к примеру, radikal.ru
2 Я не регистрируюсь. Не хочу.
3 Заливаю несколько картинок.
4 Они становятся доступными по ссылке "Все изображения сеанса"
5 Вчера залил, в сеансе они были.
6 Сегодня зашёл - нету.
7 Используются стандартная PHP-сессия. Без увеличения её продолжительности. То есть назавтра сессия удалена.
8 Используем куки для сохранения информации.
9 Вопрос, что надо сделать на сервере чтобы узнать залившего картинки назавтра?

Наверно всё-таки в моём случае не правильно связать идентификатор и сессии. Это просто некий идентификатор. 
И в случае sanich_, наверно тоже.


Список есть на сервере. Таблица user в базе данных.


Как будем по базе искать пользователя? По кею? 


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

Давайте обойдемся без переходов на личности и "распальцовки" о том кто больше знает, хорошо?

Итак, объясняю подробно.

Потому что сколько бы вы не выставили время жизни сессионой куки сборщик мусора все равно почистит все ваши сессии, которые старее 14400 секунд(по умолчанию).

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

К чему это приведет?
1. У вас будут накапливаться куча мусорных сессий. Пользователь удалил куку, сменил браузер, зашел с другого компьютера и каждый раз ему выдается новая сессия, причем старые идентификаторы так же будут оставаться валидными. А если еще учесть, что далеко не всем пользователем нужен автологин и большинству пользователям будет устанавливаться кука до закрытия браузера, то таких мусорные сессии будут плодиться с катастрофической скоростью.
2. С точки зрения безопасности считается плюсом сессий то, что они валидны лишь короткое время жизни и, злоумышленник заполучивший SID, сможет им воспользоваться только короткое время. В вашем же случае, мало того что время жизни сессий безгранично большое, так еще и количество этих сессий на одного пользователя может быть больше одной. Т.е. злоумышленнику достаточно заполучить лишь один из многочисленных SID и он сможет беспрепятственно получать доступ к данным пользователя длительное время.


Теперь еще раз подробнее про алгоритм, о котором я говорил.
Когда пользователь авторизуясь на сайте ставит галочку "запомнить меня", то генерируется некий secret key, который привязывается к данному пользователю и устанавливаются две куки на длительное время: ID пользователя и только что сгенерированный secret key.
Все, на этом на данный момент все манипуляции закончены. Мы все так же работаем с сессиями как и раньше.

Далее пользователь уходит с сайта, все сессии как положено очищаются, SID становится недействительным. Через некоторое время он возвращается и передает на сайт ID и secret key. Мы пытаемся его аутентифицировать: получаем данные о пользователе по его ID (не важно как и откуда) и сверяем переданный secret key с тем, что был получен с данными о пользователе и если они совпадают, то авторизовываем пользователя и повторяем процедуру с генерацией secret key.
Все, дальше пользователь работает, как будто он авторизовался по логину и паролю.

Т.о. все "навороты" заключаются в создании альтернативного backend'а авторизации (чем, собственно, автологин и является), что при грамотном ООП подходе не составит никакого труда и займет всего десяток строк.

Как вы правильно заметили, можно обойтись одной кукой secret key, но тогда, что бы узнать какого именно пользователя надо авторизовать, пришлось бы искать его по этому secret key, что обычно несколько накладнее. Куда проще хранить рядом с ним его ID'шник.


Нет, автологин не имеет никакого отношения к сессиям, это всего-лишь механизм "прозрачной" авторизации пользователя.

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


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

sTa1kEr, все верно. Так я и задумывал.

Добавлено через 3 минуты и 11 секунд

А других нет. 
Нет, конечно есть. Но почему бы и не хранить их вместе?

Просто, если у вас вообще отсутствует регистрация, то вам как-раз больше бы подошел вариант IZ@TOP'а со стандартным механизмом сессий и увеличенным максимальным временем жизни. Тогда можно было бы вовсе отказаться от хранения информации о закаченных картинках в БД и тем самым упростить задачу. Т.е. отказаться от хранения не самой информации о картинках, а об их принадлежности какому-либо пользователю, т.к. как таковых пользователей нету и, соответственно, нету авторизации.

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

Тогда можно поступить так же, как и с автологином, хранить ID незарегистрированного пользователя + секретный ключ. Разница будет лишь в том, что этот механизм будет работать только для незарегистрированных пользователей.

А можно оставить вашу идею с уникальным идентификатором для пользователей в виде хеша. Но тогда этот идентификатор нельзя будет менять и индекс в БД будет более тяжелым. Плюс тогда нельзя будет нигде светить этим идентификатором.

Это сообщение отредактировал(а) sTa1kEr - 25.2.2010, 23:21

заставить его зарегистрироваться.