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

Стандартные сессии вам не подходят???

 TIME + random и все в md5

uniqid()

тоже неплохая фнкция, но я сделал вот так:

md5(id юзера+time())

sanich_, спасибо, ты открыл мне глаза. 
Я тоже переделал. Но не так как у тебя.

— и не стыдно показывать?

session_id() религия использовать не позволяет?
И, если уж на то пошло, при старте сессии для нее автоматически назначается уникальный идентификатор. Алгоритм генерации идентификатора можно указать в настройках php.ini.

Не знаю как там у sanich_, у меня это уникальный идентификатор пользователя. Сессии отдельно, идентификатор отдельно. В отличие от сессий он навечно. (хотя над этим надо подумать)

а auto_increment чем не подходит?

А что это такое?   

Это 1, 2, 3, 4, 5...   

Ну если azesmcar подразумевал это, то остается только улыбнутся. 

Собственно azesmcar прав, в 99% случаев в качестве идентификатора пользователя более чем достаточно autoincrement'а.  Глобально уникальный идентификатор тут может иметь смысл разве что при отсутствии какой-либо централизованной БД, либо при наличии нескольких различных БД.

Либо при хранении этого идентификатора на стороне клиента, в куках.

Что мешает в куках циферку хранить?

Наверное то, что я могу это значение изменить и получить права другого пользователя?

И что здесь стыдиться?
id юзера - это уникальный id юзера в таблице, второго такого значения никогда не будет т.к. автоинкрементное оно.
time() - теоретически может быть одинаковое, но в сумме md5(id юзера+time()) получится на 100% уникальная комбинация.


Это сообщение отредактировал(а) sanich_ - 25.2.2010, 01:13

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

Т.е. вы по ID пользователя, лежащему в куках, определяете какие он получит права?  

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

Улыбайся, улыбка красит человека.

    

sTa1kEr, он подколол, а ты его подкалываешь 

azesmcar, спасибо, доброе слово и кошке приятно. Но ни я, ни sanich_, ни словом не обмолвились о базе.
Давайте тогда с другой стороны зайдем.
Пользователь зашел на сайт, началась сессия, пользователь ушел с сайта, закрыл браузер, выключил компьютер, как мне его завтра "узнать"?

IgorIV

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

Смотря что имеется ввиду под "узнать". Если имеется ввиду автологин, то нужно генерировать и записывать в куку некий secret key, по которому и будет происходить авторизация. Соответственно после каждой успешной авторизации старый ключ становится не действительным и генерируется новый ключ.

Если же под "узнать" имеется ввиду выдать приветствие "Добро пожаловать назад, Вася!", то достаточно ID в куке. Либо даже просто  имени.

Нафига козе боян? Зачем выдумывать непонятные, никому не нужные костыли?
У вас уже есть идентификатор сессии, зачем вам в куку еще идентификатор пользователя совать, объясните мне?

Добавлено @ 12:36

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

Это был вопрос как к грамотному кодеру, а не как к хитропому пользователю.


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

Хорошо. Предположим, сессия закончилась, пользователь ушел. Вернулся он спустя неделю с кукой в которой записан хеш md5(user_id + time), как вы его собираетесь вспоминать? Я не говорю о записи в куку ID, поскольку в таком случае я могу придти с любым ID, как я уже говорил, и система меня примет за того, кого я захочу.

Добавлено через 51 секунду

Я воспринял этот вопрос как сарказм, ответ был соответствующий.

Именно по ID.


Это уже зависит от того, зачем именно нам понадобился ID пользователя. Если для автологина или другой авторизованной операции, то см. мой пост выше. А если, к примеру, для подсчета статистики, то пожалуйста, меняй сколько влезет.

id юзера 300
time 1267095400
1267095400+300 = 1267095700

id юзера 200
time 1267095500
1267095500+200 = 1267095700

Вот опишу подробно как сделал я.

1. Вместо ID юзера числового я использовал email при регистрации - он уникальный,
email пользователя нигде в свободном доступе светиться не будет.

2. значение куки формирую так $id_session=md5($_POST['email'].time());
Если пользователь авторизовался, то установилась кука в браузере и в БД в таблице юзеров у залогинившегося юзера сохранился этот самый $id_session. Время жизни куки ставлю пожизженное)

3. Если юзер закрыл браузер, потом через некое время снова открыл, проверяю куку, если она установлена, то ищу в БД в таблице юзеров, если есть такая сессия, то вывожу на экран приветствие юзера. Если нет, то показываю форму авторизации.

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

5. После того как подобрали email, т.е. знаем что пользователь с таким email в системе существует, пробуем подобрать time(). В комбинации наша_кука=md5(email+time())

Т.е. вероятность несанкционированного доступа есть, тока надо потратить немало времени. И самое главное, прежде чем что-то подбирать, нужно знать что кеш куки строится именно как md5(email+time()), а ведь этого ж никто не знает?)))))

Жду ваши советы по улучшению этой схемы!!!!!


Это сообщение отредактировал(а) sanich_ - 25.2.2010, 15:20

Или я тупой или погода такая... Объясни мне, пожалуйста, как ты достанешь из 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

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

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

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

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