php+mySQL Интересная задача. Как подступиться?

Поделитесь, пожалуйста, мыслями. Вроде обычный каталог продукции - прас лист из базы отображается либо целиком, либо через ввод критериев по атрибутам продукции через форму формируется выборка. Основная заморочка - есть часть продукции, цена на котрую показывается всем, а часть - только зарегистрированым пользователям. Т.е. все могут посмотреть продукцию целиком - весь список, поуточнять что-то конкретное через поиск, в "секретной" части вместо цены должна быть ссылочка на регистрацию. После авторизации зарегистрированного пользователя вместо этих ссылок должны отображаться цифры цены из базы. Я думаю, понятно объяснил. Как я себе представляю, в атрибут прайс строки в таблицу базы я должен добавить пунктик типа "секретный/несекретный" (общедоступный/доступный после регистрации). Мне явно не хватает знаний в области возможностей ПХП, я не могу себе концептуально представить себе КАК это реализовать. Перекопав кучу движков каталогов/магазинов не нашёл ни в одном реализацию такой задачи. Мне не понятно, каким образом авторизацию посредством сессий или с помощью куки приварить к эскуельному запросу. Объясните в подробностях, как идиоту, пожалуйста. Как _обычно_ такие вещи пишутся? Спасибо. Очень расчитываю на помощь.

[Sensey]

Пишешь функцию авторизации пользователя... например на куках....
Если посетитель сайта является пользователем - функция возвращает true, если нет - false

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

Пишешь функцию авторизации пользователя... например на куках....
Если посетитель сайта является пользователем - функция возвращает true, если нет - false

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

Примерно понятно, но как должна выглядеть функция авторизации, через переменную глобальную статус посетителя передаётся или через хиден элементы или как? Во всех примерах я видел только раззрешение/запрет к просмотру _страницы_ или просмотр содержимого папки... Я наверное не очень понял концепцию сессий в пхп... Если можно подробно расскажите, пожалуйста. Или сошлите на пример с комментами или где почитать про авторизацию вообще поподробней... Я не понимаю самого механизма... Тупенький, наверное... Или ленивый. Новичёк, в общем.

[Hubbitus]

Задача простая и вполне стандартная.

Чтобы понять сессии, нужно просто почитать что-то толковое о них, я считаю вот это очень подходящим на это поприще.

Ну и примерчик в догонку http://php.spb.ru/php/sess.html.

Спасибо, очень полезные ссылочки.

[Sensey]

vadim1k
На куках:
в куках хранишь логин и хешь пароля юзера

Фунция авторизации :
читает куки
проверяет есть ли такой пользователь
в зависимости от результата дает тру или фалс

[aoxyz_30330]

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

[Hubbitus]

Sensey:
На куках:
в куках хранишь логин и хешь пароля юзера

Из "вредных" советов чтоли, как не нужно делать???
Больше идентификатора сессии, или незначащих в плане безопасности вещей (типа предпочтений пользователя) в куках ничего хранить не стоит!

Насколько я уяснил, мне можно вообще не заморачиваться, т.к. при выполнении session_register() или session_start() ПХП фактически сам всё определит -
"Алгоритм извлечения идентификатора. Из настроек сервера известно, что имя переменной, хранящей идентификатор - PHPSESSID (можно задать произвольное).
Если идентификатор будет найден в куках, то пользователь считается идентифицированным и использующи куки: повторно кука не устанавливается, URL не подвергаются автозамене (о автозамене чуть ниже).
Если идентификатор найден в URL (GET-запрос) или в POST-запросе и не найден в куках, то пользователь считается идентифицированным и не использующем куки: кука выставлятся (на всякий случай), URL проходят автозамену, чтобы вставить в них идентификатор.
Если идентификатор не найден ни в куках, ни в URL, то пользователь считается новым, используется ли он куки - не известно, происходит выделение нового случайного идетификатора и установка в куки, автозамена всех URL.
Таким образом, можно определить поведение ПХП:
При первом визите человека на ваш сайт ПХП не находит идентификатора; он устанавливает куку и производит автозамену всех URL и форм. При втором и последующем обращениях, если у человека включены куки, то ПХП будет каждый раз получать идентификатор из кук и соответветственно не будет производить повторной установки куки или автозаменять URL. Если при повторном посещении ПХП обнаружит идентификатор только в URL, то ПХП будет и далее пытаться установить куку и производить автозамену. Все это следует из приведенных выше 3-х правил." Конец цитаты.

[Hubbitus]

vadim1k:
Насколько я уяснил, мне можно вообще не заморачиваться, т.к. при выполнении session_register() или session_start() ПХП фактически сам всё определит -

Да, если стоит опция session_autostart, то вообще ничего не надо в общем случае, просто работай с сессионными переменными, и все, ПХП обо всем позаботится сам в большинстве случаев. К редких когда не может, тоже описано тамже (например формирование ссылок на JavaScript с отключенными куками)

[Sensey]

Hubbitus
Ты где то увидел что бы я говорил про сессии?

[Hubbitus]

Sensey:
Ты где то увидел что бы я говорил про сессии?

А разве я где-то сказал что ты говорил про сессии???

P.S. Прошу прощения за флейм.

[Sensey]

Hubbitus
Больше идентификатора сессии, или незначащих в плане безопасности вещей (типа предпочтений пользователя) в куках ничего хранить не стоит!
------------------------------

Я не говорил о сессиях.. следовательно - какой нахрен идентификатор сессии?

Я говорю про авторизацию полностью основанную на куках...

Я конечно понимаю что сессии это круто... но польза не всегда от нее есть...
Меня например удивляет когда на сайтах с 5 страничками используют сессии...

Вот глянь на мой проэкт - www.ashdoda.net
Там нет сессий... и используется авторизация которую я дал в пример... ну и иди докажи мне что такая авторизация чем то плоха? Как в плане безопасности так и в плане юзабельности....

Так что не надо мне здесь говорить про "Из "вредных" советов чтоли, как не нужно делать??"

Использовать сессии или куки - дело конкретного проэкта...

[Hubbitus]

Sensey:
Я не говорил о сессиях.. следовательно - какой нахрен идентификатор сессии?

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

Sensey:
Я конечно понимаю что сессии это круто... но польза не всегда от нее есть...
Меня например удивляет когда на сайтах с 5 страничками используют сессии...

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

Хешь пароля он конечно не пароль, но не вникая в подробности, давай посмотрим простую разницу реализаций. Смотри, перехват кук впринципе не сложная и распространенная ситуация, я не говорю что сесии, хранящие в них идентификатор от этого защищены, но давай посмотрим последствия:
1) ХХХ получил чужую куку с логином и хешем пароля в ней. Что он имеет? Полный доступ к тому сайту от имени пользователя, пока он когда-нибудь, может быть, не сменит паролей. ХХХ может себя никак не обнаруживать и ждать момента когда смогу сильно навредить (жадть момента), много украсть (ждать прихода денег в аккаунт), постоянно быть в курсе конфиденциальных данных и т.д. кому что по вкусу.
2) YYY получил чужую куку с идентификатором сессии. Впринципе, тоже очень нехорошая ситуация, однако, давай посмотрим чем она отличается от ситуации ХХХ: Может так статься, что он вообще получил ее уже после того как сессия закрыта, тогда он вообще никак и не сможет ей воспользоваться (например если троян ее прислал на мыло, и проверили его поздно). Вариант хуже - он все-таки получил его пока сессия жива. Да, тут он имеет доступ к аккаунту пользователя впринципе, такой же как и ХХХ за некоторыми очень важными исключениями (я кстати не говорю встроенные еще защиты секьюрности сессий, пусть ничего их этого не используется), а именно: Он имеет доступ к аккаунту пока жива сессия. Тоесть, если он не сменит авторизационной информации, то имеет этот доступ один раз всего. Далее, если он сменит аторизацию, то при следующем заходе законного пользователя, тот это сразу же обнаружит и как легальный пользователь, скорее всего отнимет свой аккаунт назад (через восстановление, через поддержкуи т.д.)

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

[Sensey]

Hubbitus
Ты где то видел что бы я говорил о недостатках? Просто не надо говорить что авторизация на куках это что то совсем древнее и нехорошее...

Спорить про куки и сессии можно бесконечно.... пусть человек использует то что ему удобно...

[Hubbitus]

Sensey:
Ты где то видел что бы я говорил о недостатках?

Да, это видел:

Sensey:
ну и иди докажи мне что такая авторизация чем то плоха?

Ты сам просил показать чем она плоха, я и расписал вкратце. А спорить я с тобой совсем не собираюсь.

Sensey:
Просто не надо говорить что авторизация на куках это что то совсем древнее и нехорошее...

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

Sensey:
Спорить про куки и сессии можно бесконечно.... пусть человек использует то что ему удобно...

Конечно выбирать ему, я ничего никому не навязываю - спрошено было на форуме, стараюсь объяснить достоинства и недостатки того или иного метода. А спорить стобой, как и говорил выше - совершенно не собираюсь. Да и потом было бы из-за чего (тут не о чем спорить, а вообще в конструктивном споре рождается истина)!

То, что я делаю, как раз из 5 страничек Ну может чуть больше...

[SergoZD]

Вопрос по php+mysql, посему решил не создавать новой темы.

Есть некая функция

PHP код:

function query ($query)
{
   $result=mysql_query($query) or error("400 Bad Request","<br><b>Error:</b> ".mysql_error()."<br><b>due execution query:</b> ".$query);

   while($res=mysql_fetch_assoc($result))
   {
      $resalt[]=$res;
   }
   return $resalt;
} 


которая преобразует результат запроса в ассоциативный массив
есть две проблемы:
1. если результат запроса нулевой, то происходит благополучное вываливание апача с еррором
2. хочется через эту же функцию выполнять запросы "UPDATE DELETE" и т.п., дающие в качестве результата boolean (при них выдается ошибка про неподдерживаемый тип данных в mysql_fetch_assoc)
Как решить такую задачку?

Для второго варианта делал проверку на тип boolean, и если не совпадает, то выполнял цикл while, но вот 1 проблемы это не решало...

[EvroStandart]

SergoZD:
1. если результат запроса нулевой ...

А разьве $result нельзя проверить на размер или количество элементов?
Я вообще прочитал в умной книжке про PEAR DB. Пользуюсь и радуюсь

[Naked]

насколько знаю, нужно заюзать вот так:
1. $result=@mysql_query($query)...., если ставишь @, то на экран ничего не выводится от результата САМОЙ команды...
2. $res=mysql_fetch_array($result, MYSQL_ASSOC)
А для bolean можно попробовать возвращать mysql_num_rows ($res), по-моему при булене она вернет 0...