Cookies, мать их за ногу! :(

[CRZ Factor]

SetCookie ("$userid", "$userkey", time()+3600);

$userid - номер пользователя в бд
$userkey - его оригинальный номер, полученный с помощью uniqid;

Эта строка откладывает куку, но при обращении к ней как к переменной мне доступна только $userkey! Те вся эта кука стала просто-напросто ключом! Как сделать так, чтоб была доступна и переменная $userid? Ведь каждый раз искать в здоровой БД по 20-значному $userkey - хана ресурсам

И еще вопрос: какое будет имя переменной после того как будет получена кука (уже отложенная) ?

Имеется вариант такой: ($uderid[$userkey], time()+3600);

И потом обработать ereg или там unpack... Но можно ли как-то все сделать поэлегантней?

[Sirgo]

SetCookie ("$userid", "$userkey", time()+3600);

$userid - номер пользователя в бд
$userkey - его оригинальный номер, полученный с помощью uniqid;
***откушено***

И еще вопрос: какое будет имя переменной после того как будет получена кука (уже отложенная) ?

Все просто. В руководстве написано:

setcookie (string name [, string value [, int expire [, string path [, string domain [, int secure]]]]])

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

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

Но, возможно, это слишком заумно - самому выдавать куки и запоминать их. Попробуй воспользоваться сессиями (только ПХП 4). Очень удобно!

[CRZ Factor]

Разобрался я с куками, на будущее мож кому пригодится:
SetCookie("www.address.com",$id, time()+3600, "/", "zona.com") - отложитса кука для текущенго юзера с составляющей в имени = www.address.com, посылающая на сервак ДО http- заголовков переменную $id, зона действия которой разрешена по адресу www.zona/, причем слэш указывает что по всему домену. Если бы после слэша была указана имя директории, то куки действовали бы только при обращении браузером (или чем-то другим) к этой директории.
----------------------------------------------
2Sirgo: а как сделать без кук сессии без постоянного ввода пароля? Те юзер заломился, ничего не вводя, и сайт его узнал? По моему, без куков никак, а так, безусловно, сессии - руль.

[Sirgo]

Ну тут нет ничего сложного. Есть такая переменная session.cookie_lifetime - по умолчанию она в нуле, т.е. юзер закрыл браузер - кука удалилась. Соответственно, если ентой вещи присвоить какое-нить значение, то это будет время жизни. Помоему так.

[CRZ Factor]

Ну это просто другой спосбо отложить куку... Смысл в чем: вообще без куки невозможно сделать клубную систему, не требующую при каждом заходе на сайт даже от регестрированного юзера ввода своего логина и пароля. Отключи куки в браузере и залезь ну даже вот на flasher.ru - сайт тебя не вспомнит! И если все время будут куки вырублены, он тебя не сможет вспоминать А по последним данным (на phpnet.ru писали), вроде как собираются ваще куки запретить, мол, хакеры использую дыры в браузере, через куки творят гадости (что кстати, вполне возможно!)... Так что как писать сайт, не знаю... С куками или каждый раз подтверждение????

[Sirgo]

У меня сейчас та же проблема. Хочу сделать типа спайлога счетчик, но внутренний, на пхп. Так вот, на спайлоге написано было где-то следующее:

До 98% пользователей Рунета (русскоязычного Интернета) позволяют установку cookie-файлов на своих компьютерах. Пользователи, запрещающие установку cookie-файлов на своем компьютере, идентифицируются только в пределах одной сессии по сайту. В этом случае идентификация осуществляется на основе четырех параметров: IP-адреса, установленного броузера, глубины цвета и установленного экранного разрешения.

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

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

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

Мне вообще кажется, что куки запрещать не зачем. Нужно просто сделать на передней панеле браузера кнопку-тумблер, у которой 2 положения - "обычная работа" и "инкогнито". Во втором случае естесств. куки не выдаются и не принимаются.

[CRZ Factor]

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

[Demon1983]

Я тут писал программку типа форума на ПХП с использованием SQL. Программка е...т сотрудников, когда шэф за границей. Он кидает распоряжения, а она их разбрасывает куда нужно и при этом проверяет даты. Сотрудники вносят предложения, результат, затраты....куча таблиц в итоге. Я думаю через месяца 2 база разрастется.....хотя я внес функцию удаления сообщений при админских правах. В общем, к чему это я......а.... так вот с кукями тоже беда была, но ничего вроде вовремя подчищал их(программно), где надо запоминал юзающего.... ничего, вроде пашет.....

[sapenov]

<?session_start()
if(!isset($auth)){echo"Пошел в жопу ! Зарегистрироваться !";}
else {показать страницу и тд}
?>

[sapenov]

кстати при использовании сессий задействуются И КУКИ И уникальное адресное пространство памяти (заумно наверное, ну и ладно...)