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

Но дает ли это что то?

А зачем логин и пароль писать в сессию?   

НУ мне всегда казалось что так безопасней...
А то куки любой дурак подделать может....

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

И как вы себе представляйте сайт без Cookie и session ?=-)
ТОгда вообще любой вася под чужим логином зайдет и деньги украдет!

Я не говорил что Cookie и session не нужны,  только зачем Вам там хранить пароль?  

Muerto, В сессии хранится логин и id пользователя. Но никак не пароль. 


P.S.
Зачем хранить пароль? Есть подозрение, что на каждой странице идет запрос к базе и проверяется есть ли такой пользователь 

Ну смотрите, я не заявляю что я уж супер профи...

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

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

Так же читал статьи о безопасности, никогда не советуют делать select ... username=uname password=password

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

Muerto, Почитайте разницу кук от сессии. Особенно где хранятся данные. При авторизации все данные хранятся в сессии.  И система работает с сессией, которая хранится на сервере и её нельзя подделать. Работайте с сессией и не нужно будет проверять доступ на каждой странице.

Это сообщение отредактировал(а) capitan - 16.7.2010, 11:03

А почему пароль не стоит хранить?
А как мне убедится что пользователь не взломщик?
У меня id и username пользователя, любой получить может!

Muerto, 

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


Так как существуют способы несанкционированного доступа к файлам сессии. А тут вам раз и пароль   


Потому правильно - пришел пользователь на сайт, ввел логин и пароль - дошли они до Вашего логин-контроллера, Вы в логин контроллере проверили, есть ли у вас пользователь с таким логином и паролем (при этом в базе храните не пароль а хешь пароля) - положили в сессию либо id, либо объект пользователя - все! Пароль больше нигде не упоминается.

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

1. Зачем?
2. Работать с сессией.
3. Ну и что? Как он подставит все это в сессию? Она на сервере лежит, а не у клиента.

Добавлено через 1 минуту и 39 секунд
Vasay, а каким образом можно подменить сессию не имея доступа к серверу? или ID сессии ?

И в сессию их тоже любой положить может? Раз так, то наверно и извлечь    И если вы там пароль храните - то значит и его любой извлечь может.

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

А по теме,  как же все же лучше, допустим если хранить agent ip username id
Лучше делать как?


Или 


Или же 

И затем как бы можно делать explode

Это сообщение отредактировал(а) Muerto - 16.7.2010, 11:15

Muerto, 3-й вариант - это извращение. 1-й или 2-й  какой больше нравится. Я использую 2-й. Группирую по блокам.

Добавлено через 5 минут и 16 секунд
Vasay,  пояните все таки своё высказывание :
  
Не имея доступа к серверу и не зная ID сессии, как можно подменить?

Подмена сессии как раз задача вообще тривиальная - если не используется https то узнать Session ID сможет любой "нехороший человек" имеющий доступ к каналу связи (ваш сосед по локалке, недобросовестный админ провайдера, а если у Вас или вашего провайдера еще и спутниковый download   )...

Но я говорил не про это.


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

Т.е. храня пароль в сессии или вообще где либо в открытом виде - Вы подвергаете пользователя дополнительным рискам.

Мне нравиться третий вариант тем что если я проверяю if(isset($_SESSION ..
То не нужно писать несколько раз isset && isset && isset для ip agen username id
А все храниться в одном месте!

Добавлено через 10 минут и 10 секунд
И все же если вернемся к безопасности, неужели agent и ip нас могут защитить?
А если человек с разных браузеров заходит?

агент  - защита от дурака
ip - уже что-то, но у многих он динамический.

Если работаете с деньгами - используйте хотя бы https

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

сори дабл пост.

Это сообщение отредактировал(а) Muerto - 16.7.2010, 14:29

Пароль и в базе надо хранить в хешированном виде - это как минимум..

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

P.S. Если взломщик получил доступ на сервер - ему глубоко наплевать, что там в сессии хранится. Он может слить базу и посмотреть что там. А если там пароли в открытом виде - это конец вашему сайту, причем полный.

Это сообщение отредактировал(а) capitan - 16.7.2010, 14:55

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

Вот и меня интересует, пользуется сайтом к примеру 2000 человек, и не будет ли плохо, если на сервере лежит 2000 файлов сессий?

Если ОДНОВРЕМЕННО 2000 человек зайдут на сайт (одновременно - в течении 10 минут - время жизни сессии), то да, будет 2000 сессий. Но с таким наплывом посетителей сайт либо дохнет сам, либо переходит в другую категорию обслуживания, на более дорогой тариф (и, вероятно. с более другими разработчиками)   

capitan, А что мешает хацкеру, если он не знает какой пароль и получил доступ к серверу тупо взять и сменить пароль на 12345 и захешировать?

Я никого не переубеждаю, это всего лишь обсуждение...

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

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

Это сообщение отредактировал(а) Muerto - 16.7.2010, 16:32

А что мешает их в сессию засунуть и считывать оттуда???




Вам так сильно это интересно? Зачем? Ваш подход не предусматривает высоконагруженный проект.

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

CruorVult, Да никто мозги не пудрит, все верно, дело во мне- я не знаю как сделать безопасно без проверки пароля.

Но вы забывайте одно, пароль в сессии храниться закодированный, причем так что я с трудом верю что его кто либо сможет раскодировать, поэтому даже если я вам скажу мой пароль, вы ничего с ним не сделайте!
т.е. в систему вы с хешом типа UHFgfd6435dfd7345Fsd43fdg745fdhdf зайти не сможете , в тот час как 
Мой пароль к примеру это кошка:


Ура, вы узнали что мой id Это 1 username это admin хэш пароля UHFgfd6435dfd7345Fsd43fdg745fdhdf
Как вы узнайте что нужно ввести koshka в пароле если мой алгорит кодирования не доступен в паблике?

Добавлено через 3 минуты и 48 секунд
capitan, Ну у меня есть проекты и похуже, на старом скрипте, которые тянули и по 10к хостов в день...

Это сообщение отредактировал(а) Muerto - 16.7.2010, 16:50

Мде!
Как Вы думаете какой запрос будет выполянтся быстрее:
1) поиск по id(primary key)
2) или по хешу

Ах да, я забыл, вам производительность не главное  

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

перечитайте внимательней эту тему - может и поймете 

Что-то смешались в кучу кони люди сессии и куки, а точнее session cookie и permanent cookie.

Как работает сессия?

Пользователь заходит на сайт, сайт делает session_start(), что заставляет произойти следующее:
1) на сервере создается файл сессии с уникальным идентификатором сессии в качестве имени
2) браузер пользователя устанавливает у себя session cookie для вашего сайта, который содержит этот уникальный идентификатор.

Именно таким образом сайт "узнаёт" пользователя при дальнейшей работе. Он спрашивает session cookie для себя, браузер ему отдает её содержимое, в содержимом хранится идентификатор сессии, сайт достает данные для этой сессии из файла, созданного в шаге 1. Это все происходит прозрачно для вас, благодаря механихму сессий.

Если я узнаю идентификатор живой сессии на сайте и подменю его в своей session cookie для вашего сайта, то я сразу "зайду" как другой пользователь. 
Для session cookie идентификатор сессии - это единственное что хранится на стороне клиента. Все остальные данные, которые вы достаете/кладёте из массива $_SESSION хранятся на стороне сервера, в файле, созданном на шаге 1.

Безопасность тут обеспечивается тем, что я не могу узнать имена существующих сессий, если только другой пользователь сам мне его не отдаст или я у него его не украду. Кража сессионых кук - весьма распространённый метод взлома. Защитить пользователя от него вы можете лишь в области javascript, обеспечив экранирование пользовательского ввода, чтобы злоумышленник не смог на вашем сайте где-то подставить вредоносный javascript код. (например на какой то доске объявлений, забудете заыкранировать и сразу встречайте js-injection)

Session cookie удаляется браузером после закрытия. Она временная.

Cookie

Теперь касательно permanent cookie. Они используются для того, чтобы сайт узнавал пользователя даже после того, как браузер был закрыт. permanent cookie живут столько, сколько им отведено по expire времени.

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

Вопрос - как обеспечить безопасность этой куки? Чтобы злоумышленник, подделав или украв permanent cookie пользователя, не смог ей воспользоваться.

Ответ: обычно в такую cookie подкладывают уникальный hash, который злоумышленник знать не может, это спасает от подделки. hash пароля - один из возможный путей, но недостаточно секьюрный. Обычно хешируют связку типа useragent+ip+password. При подключении пользователя с permanent cookie сайт должен взять его текущий useragent+ip+password, захешировать и сравнить с тем, что в cookie. Не совпадают? - До свидания, логинься снова. 

От воровства этих cookie спасаются точно так-же, как от воровства первых - экранировать ввод. Не допустить javascript-injections.

CruorVult, А с чему вы взяли что выбор данных идет по хэшу?
Выбор идет по id and username а патом уже кодируется пароль из базы в хэш

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

по мне так пожалуй самое актуальное это хешировать к примеру связку id username password таким образом ну просто никогда до чистого пароля не добраться имхо

Это сообщение отредактировал(а) Muerto - 16.7.2010, 17:22

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

CruorVult, Ну во первых можно хешировать связку, а не пароль в чистом виде к примеру пароль ip id и username
А пароль я хочу проверять потому что все остальное можно подделать и узнать имхо

а так, можно и в Cookie хранить, сказать что есть большая разница, так нет.

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

Это сообщение отредактировал(а) Muerto - 16.7.2010, 17:26

вот именно

 

Добавлено @ 17:25
Прочитайте что написал smartov 

Это сообщение отредактировал(а) CruorVult - 16.7.2010, 17:26

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

Вы мне лучше если вы очень умный, предложите реальную схему работы которая будет лучше моей, и которую не каждый ламер взломает.
Опять же взломают пользователя = вас, а не сервер.

Да, я не хочу хранить пароль, тогда что храним.
У вас есть страница Login.php logout.php и функция проверки данных которая висит вверху страницы

Это сообщение отредактировал(а) Muerto - 16.7.2010, 17:31

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

Поймите если хакер украдет айди сессии и запишет себе в куки - то соответсвенно все данные которые хранятся на сервере в сессии будут доступны, соответсвенно и ваш пароль. 

Это сообщение отредактировал(а) CruorVult - 16.7.2010, 17:40

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

Если у пользователя хакеру удалось как то получить сессию а точнее её ID, то тут ничего не спасет уже!

Это сообщение отредактировал(а) Muerto - 16.7.2010, 17:47

...хранил id и пароль...

и вы опять пароль хотите хранить?

CruorVult, Простите, очепятка, хранил id и логин
И давайте как то более к делу.

Допустим я хочу хранить любое но не пароль, даже не в закодированом виде ,и даже не хэш id+username+password+ip ибо вы утверждайте что это плохо

Что мы храним?
И раузмеется используем куки потому что меьнше мусора на сервере, так?

Это сообщение отредактировал(а) Muerto - 16.7.2010, 17:54

если там еще будет пароль и в базе пароль не будет захеширован, то случаев взлома будет намного больше 

CruorVult, Но какая разница если пароль в базе простой а псевдо пароль в куки который состоит из хэша реального пароля ip id и username

Предположим даже что кодирую md5

делаем md5($id.$username.$password.$ip); 

Берем данные к примеру

Оригинальный текст:3CruorVultzoloto198687.6.2.32
Шифр md5:8df8a6c6eb3f2389631a4ef87a263c06 
*Данные настоящие!*

 Теперь сессия выглядит так предположим 8df8a6c6eb3f2389631a4ef87a263c06

В базе лежит твой zoloto1986

Ты узнал шифр, 8df8a6c6eb3f2389631a4ef87a263c06

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

Оригинальный текст:3CruorVultzoloto1986
Шифр md5:46b271cda57d3bdae6df239777cae775

И что тебе это опять же дает

форма логина это
логин его я знаю CruorVult
Но то что ты получил в куки это хэш сочетания id username и password и в базе пароль твой zoloto1986
а у тебя 46b271cda57d3bdae6df239777cae775

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

Что бы опять же мы друг друга понимали лучше, хэш твоего пароля был бы 34916fe3528aad746078d34951b40014
но здесь же 46b271cda57d3bdae6df239777cae775

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

Muerto, есть мнение, что опираться на IP в защите куки неправильно, так как мобильные устройства при переезде с соты на соту могут его поменять. Лучше опираться на юзер агент.

Добавлено через 2 минуты и 30 секунд
Muerto, чтобы "взломать этот случай", достаточно сообщить серверу перехваченые IP адрес (да-да он тоже хидером передается ;) ), юзер агент и куку... 

Я потерял нить спора. О чем спорим то, если все что я написал и так вам известно.
(Про https советы уже были)

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

резонное замечание

ksnk, Читаем тот пост, то что после Мне это не дает ничего, уберем ip который осложняет ситуацию как хакеру так и для пользователя неудобство
Я там сказал что ip по любому использовать не собираюсь
Процетирую опять


Это сообщение отредактировал(а) Muerto - 16.7.2010, 18:58

Muerto, то есть ты утверждаешь, что паролть никто не узнает? А пароль уже и не нужен, если на сайт удалось пролезть с нужной учетной записью...

ksnk, я так и не понял где кто кого ломает. 

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

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

Собственно с моей точки зрения итоги спора такие:

1. Взломать если очень хотеть и есть дыры в безопасности - не проблема
2. проверять пароль или нет, если взломают сервер - значение не имеет
3. если можно перехватывать данные опять же не важно как и что хранить
4. не закодированный пароль хранить нельзя, и цель защиты от ламеров в клубе, то если хранить кодированный пароль то тот ламер ничего с этим не сделает.
5. куки или сессия не имеет значения пока данные закодированные...

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

Это сообщение отредактировал(а) Muerto - 16.7.2010, 19:25

Muerto, куки , а также все хидеры, выдаваемые броузером ВИДИТ провайдер, любой участник вашего сегмента локальной сети, любой из цепочки передающих-принимающих узлов интернета.

Muerto 

Похоже Вы уже сами себя запутали. Давайте расставим запятые над i   :

1. Пароль пользователя никогда не хранят в открытом виде - ни в базе, ни в сессии, ни в файлах.... так как если Вы как программист, или администратор допустили ошибку и позволили взломать ваш сайт/сервер/базу -  то злоумышленник получает пароль пользователя, который, с большой вероятностью, используется не только на вашем сайте.


2. Если Вы не используете шифрование канала (в самом простом случае https) - то любой, кто может прослушать канал (ваш сосед, админ провайдера, "кул хацкер" сканящий спутниковый канал (если у вас или у вашего провайдера спутниковый download), "кул хацкер" сканящий открытый (или плохо закрытый) wi-fi канал) - спокойно может подделать сессию, какой бы сложный алгоритм идентификатора сессии вы бы не использовали.

Так что если у Вас используется работа с деньгами - то простой http вам противопаказн!!! 

А теперь я расскажу как все должно работать.
1. Все необходимые данные логин, никнейм, id и т.д. которые выводятся на каждой странице сайта хранятся в сессии. Дабы не делать постоянные запросы в базу и не нагружать её.
2. В куке хранится логин и хеш пароля, который лежит в базе. При заходе на сайт проверяется сессия. Проверяется не через isset, а через !empty. Например проверяем id пользователя. if (!empty($_SESSION['id'])) { пользователь авторизован }  иначе проверяем куку. Если в куках есть логин и хеш пароля - запрос в базу. Если связка логин - пароль в базе есть, пишем в сессию необходимые данные и пускаем пользователя дальше.  Если данных нет или нет кук - посылаем на авторизацию.
3. При секретных операциях, например, при смене кошелька, запрашиваем у пользователя пароль и работаем с полученными данными.
4. Для суперсекретных операций используем https  или службу поддержки, которая сама вносит изменения.
5. При залогинивании пользователя пишем в базу с какого ip и время захода. И показываем эти данные. Юзеры в случае чего сами скажут, если кто-то вошел под их данными.

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

capitan, 



не надо хранить хеш пароля в куках. 

Если злоумышленник получает хэш пароля - то у него есть шанс получить пароль через BruteForce.

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

Было бы очень интересно услышать, как работает галочка "сохранить пароль" в окне авторизации...

Как сделано здесь - не знаю, но  вообще достаточно положить в куки некое Session ID. Как его генерировать - это уже другой вопрос, но точно не как хеш от пароля.

pforummember_id=XXXXX; pforumpass_hash=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx; достаточно открыть куки и посмотреть...
 sessionId подразумевает, что где-то на сервере будет организовано хранилище данных с неопределенным (4 недели?) временем хранения. Чем наличие этого sessionId будет секретнее хеша пароля в куках?

ksnk, 



ну что сказать, 


Наверно, стоит потратиться на более новую версию форума.  Может и ломать так часто не будут.


Кстати, ща посмотрел доки к spring-security 3

Самый примитивный способ который они предлагают:



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

Более безопасный вариант. предлагаемый spring-security - с использованием базы данных с такой табличкой:



Добавлено @ 00:35


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

а вот как раз знание хеша пароля в 90% случаев даст сам пароль, так как пользователи редко придумывают пароли вида "hIn4ak8Bei7hBgHGgA71Q". чаще пароль - это что-то типа "Msha123" И такие пароли легко восстанавливаются из хеша методом перебора с применением словарей. 

Это сообщение отредактировал(а) Vasay - 17.7.2010, 00:36

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



Вот что выдаст


И выходит, изменяешь пару символов и у тебя уже свой метод кодировки,и хацкеру ещё надо будет узнать какой он...
А в случае SHA-512 я не знаю если это вообще реально  не взломав сервер, да и просто blowfish

Это сообщение отредактировал(а) Muerto - 17.7.2010, 00:56

а зачем тогда пароль в алгоритме хеширования?

Vasay, ну если уже храните пароль, так не стандартным хешем...

1) вот специально разработали REST, чтобы сессии не использовать, не хранить их все на сервере
http://ru.wikipedia.org/wiki/REST
http://en.wikipedia.org/wiki/Representational_State_Transfer

2) на этом форуме, вроде бы используется md5crypt($db_name,$db_name.'-'.$db_pass) (или просто md5) чтобы сравнить сессию в cookie нужно получить хэш с  md5crypt
$db_pass - как "соль", обратно декриптографировать нельзя и перебрать соответственно нелья, так как $db_pass не известно.
(единственное что в базе пароль в открытом виде... не хорошо)


Это сообщение отредактировал(а) gcc - 17.7.2010, 05:16

А можно подробней об REST я чет ничего не понял...
как мне это поможет не использовать сессии?

Muerto, я только что набрал в гугле и не нашел...

но это видел! 
вот человек пишет, что надо использовать REST и никаких php сессий http://forum.vingrad.ru/index.php?showtopi...t&p=1433929

тут написано где это есть http://en.wikipedia.org/wiki/Representational_State_Transfer
оно есть только во фреймворках, почему-то
я в книге видел, вроде бы, где это детально рассказывалось по perl'овому фремворку MVC Catalyst, но сейчас искать надо...

тут тоже не нашел 
http://search.cpan.org/search?m=all&q=rest&s=11


PS: кто использовал, тоже, интересно бы увидеть примеры...

Добавлено @ 14:24
Muerto, это если у тебя зарегистрировано 10млн человек, или если порно сайт с 100млн хостов в сутки, и таблицы из сессями занимают сотни млн. строк, то тогда не красиво сессии хранить... и особенно елси красиво все сделано на NoSQL, а сессии хранить - не в тему будет...

а в других обычных случаях можно использовать обычные сессии

Это сообщение отредактировал(а) gcc - 17.7.2010, 14:27

У меня вот например сервер VPS, лимит открытых файлов 3к, я так понимаю сессия  считается какоткрытый файл?
То тогда если у меня десяток сайтов, легко можно лимит превысить ...

Очень заинтересовал этот REST
Но таки нужен пример использования, а то я ничего не понимаю =-(

Добавлено @ 15:43
Поскольку в PHP пока еще нет реализации REST то не оч актуально

Нарыл вот это http://habrahabr.ru/company/Techart/blog/83442/ стоит почитать

Да и вообще REST из того что удалось выучить за 5 минут, это никакая не замена COOKIE или SESSION а просто другой подход разработки...

Это сообщение отредактировал(а) Muerto - 17.7.2010, 15:59

И это очень стоит почитать http://habrahabr.ru/blogs/php/46032/

Цитата: . Дополнительная информация так же может быть сохранена в куках. В случае если требуется сохранить большие объёмы данных, их можно уложить в базу данных, авторизационную информацию стоит оставить в куках.

Это сообщение отредактировал(а) Muerto - 17.7.2010, 16:04

Muerto, вот тут вот написано: http://www.ibm.com/developerworks/ru/library/wa-aj-resttip/

gcc, то есть REST - это просто возможность не передавать не обновленные данные клиенту? как это поможет избежать куков и сессии?

ksnk, ну я ссылки привел там где рассказывается, и вот тут вот человек писал что можно не использовать сессии пхп и использовать REST http://forum.vingrad.ru/topic-199324/view-.../p-1433929.html 

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

для обычных сайтов - достаточно обычные сессии
вродебы, это ТС ищет реализацию, а не я... 

Это сообщение отредактировал(а) gcc - 17.7.2010, 17:15

Блин, ну я прямо не знаю.. 
Muerto, ты задаешь вопрос, тебе на него отвечают, а ты упорно стоишь на своём мнении..  Так нафига тогда вопрос задавать..
Объяснили же..  В сессии надо хранить максимум id пользователя..  Пользователь закрыл браузер, сессия сдохла..  После этого надо авторизоваться заново..  Если необходим постоянный вход, то можно совершенно любую белиберду в куки сохранить и одновременно в базу (желательно, чтоб эта белиберда была уникальна и зависела от каких-либо данных пользователя, включая IP, агент и прочее)

Photon, Да я не против, я все выслушал и думаю как делать.

Добавлено @ 10:34
Кстати раз тут уже обсуждают разницу в куках или сессиях

Я почему не люблю куки, так это потому что их нельзя везде взять и объявить...
Если пытаться создавать их после хедера, где нибудь в body то методом php у меня это не выходит... 
выдает ошибку...

И в пользу кукис есть новый прикол

http://php.net/manual/en/function.setcookie.php

И ещё один момент... я не уверен что тот кто это написал прав но все же


что это за куки на serverside есть? ведь вся идея кук что инфу храним у клиента, или я что то упустил?

Это сообщение отредактировал(а) Muerto - 18.7.2010, 10:42

Тут имеется в виду, что до завершения скрипта куки будут еще действовать..  Они-то передаются на сервер браузером при запросе..
Поэтому если ты их где-то ниже по ходу выполнения используешь, то неплохо бы их удалять из $_COOKIE

Видимо, автор примера считает, что после кода удаления куки может исполнятся еще другой код, который будет думать, что кука все еще жива $_COOKIE['TestCookie'] установлен, так что пристрелить эту переменную может оказаться полезно для душевного здоровья. Хотя в следующей итерации исполнения скрипта кука исчезнет сама...