sTa1kEr, Вы или тролль или немного глуповаты?



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


Мне все равно чего там будет делать сборщик мусора. Я его как не трогал, так трогать и не собираюсь.


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


Ну и в чем разница между sekret key и session _id? Я предлагаю сделать систему прозрачной, в тоже время по надежности она не уступит вашей. А вы предлагаете лишнюю прослойку и добавляете излишней логики.


Внес некоторые правки. Разницы опять не вижу. Разве что, только в том, что в Вашем варианте присутствуют излишние условия.


Надо еще десяток лишних строк кода написать?! О ужас!


Да не надо sekret key, он несет под собой ту же смысловую нагрузку, что и id сесии и спереть его можно точно так же, в течении сессии. Куда проще - не значит - куда правильнее. У нас работал программист, которому было куда проще сделать копипаст, чем переписать код под новые условия для возможности его повторного использования.



А вот вырывать из контекста не нужно.


При чем там был автологин вообще понятия не имею. Учитесь понимать собеседника.

И еще добавлю, что бы не было недопонимания: не знаю как в вашем случае, в моей практике большинство веб-морд проектов живет на нескольких серверах. Соответственно и сессии хранятся не на диске а во внешнем хранилище (MySQL, Memcached, Memcachedb, Redis), соответственно, как бы не хотелось, но идентифицируются сессии - правильно! - по строке из 32 символов. Я это к чему? Ну, как бы опять же, про экономии на разнице в производительности индексов по строке и инту - это экономия на спичках, которая может стать серьезной проблемой только в случае, если у вас таблица вырастет за гигабайт.

Добавлено @ 13:25

Это уже вопрос конкретной реализации,  не нужно путать людей излишней информацией.



Эм, простите, а разве Вы используете не стандартный механизм сессий? У вас свой написан?
И опять же, прошу мои слова не коверкать. Я не увеличиваю время жизни сессии, я увеличиваю время жизни идентификатора сессии, что дает те же самые возможности, что и в случае с sekret key. Просто у меня отсутствует ID юзера, ибо смысла я в нем все так же не вижу.

Боже мой, сколько агрессии!  Мой вам совет, учитесь быть сдержаннее.

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

Это не агрессия мой юный друг, это праведный гнев, абсолютно оправданный по отношению к столь самоуверенной личности.



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

  

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

Это сообщение отредактировал(а) sTa1kEr - 26.2.2010, 15:44

Как будто со стенкой разговаривал все это время. Придется, видимо, объяснять как для умственно отсталых.

Возьмем в пример ваш собственный метод. 
Уберем оттуда ID пользователя, а в качестве secret key подставим значение ID сесии. Как и в Вашем случае, при применении настройки автологина, идентификатор сессии будет записан куда-то на постоянное хранение. Я вообще, если честно, не понимаю, чего Вы с такими способностями к логике в программисты записались. Попробуйте другое направление, в секторе обслуживания например.

Ага, ну вот мы и пришли к общему знаменателю 

Реализуем полностью мой метод со всеми "ненужными прослойками" в виде backend'ов прозрачной авторизации и заменяем в нем set_cookie() на session_set_cookie_params(), а md5(uniqid()) на session_id()  

Бгг, наконец-то договорились.

Что-то Вы очень долго шли к понимаю как без secret key и user_id можно все это на обычном идентификаторе сессий построить. Возможно со временем опыт придет.



Я рад, что Вы усвоили принцип хотя бы в таком виде.

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

И еще я хотел бы добавить, генерация secret key при помощи session_id() усложняет задачу тем, что нам придется тщательно отслеживать перегенерацию SID и следить, что бы в базе всегда хранилось актуальное значение. Лучше, как говорится, держать мух от котлет отдельно  

Это сообщение отредактировал(а) sTa1kEr - 26.2.2010, 18:30

Тут два вариант: или своей глупостью или излишней самоуверенностью. В любом случае, не я это начал и не я это закончил.


Что-то мне подсказывает, что тут достаточно сделать session_regenerate_id сразу после того, как вспомнили пользователя. Ну и опять же, secret key = session id. Потому тут не усложнение а упрощение из secret key & id в session id.
Впрочем, это уже, скорее всего, на вкус и цвет.

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

Это сообщение отредактировал(а) sTa1kEr - 26.2.2010, 19:05

Полемика на эту тему должна продолжатся во флейме.

Согласен. Придется это сделать мне.