Веб программирование
- Автор темы gram
- Дата начала
zmc
Участник
Majik13":31lh9713 сказал(а):
Совершенно голословное утверждение. Чем именно такая авторизация принципиально надежнее стандартной авторизации, которая реализована в библиотеках вроде php-lib или pear, когда после пересылки логина с паролем посетителю ставится кука с ID сессии (с некоторым ограниченным сроком действия, скажем на полчаса, на тот случай, если человек отошел от комьютера и забыл сделать logout)?
Собственно ничего страшного не произойдет. ID сессии в этом случае можно "прокидывать" через URL'и, правда при этом все они приобретут несколько неприглядный вид вродеMajik13":31lh9713 сказал(а):
http://www.somwhere.com/index.php?sID=0c23acf4322dfeb2
Это требует лишь дополнительной работы от разработчика веб-сайта, а если пользоваться уже готовыми библиотеками, вроде той же php-lib, то и вообще никаких дополнительных усилий не понадобится.
Majik13
Старожил
zmc":3mnc8t62 сказал(а):
1. Факт, что сотню раз, вводя в окошке мэйл.ру свой логин и пароль я попадал на страницу с заголовками писем предыдущего чтеца. И это не проблемы с кэшем.
2. Куки - относительно частный случай, реален, если есть возможность использование программирования. Случай, который я выше указал, с папкой и прямым УРЛ понятен?
3. Хттп авторизация - одноразовая, PHP - авторизация для каждого скрипта (условно). Я так понимаю, что если время куки истекло, то авторизация прости прощай? Я не прав?
P.S. Я знаю, что это все все равно решается какими-то методами и работой головой, я рассматриваю недостаки в чистом виде.
zmc":3mnc8t62 сказал(а):
Вот-вот, речь о том и шла (лично я об этом говорил), что это и есть разница между куки и сессиями. Если куки не ставится, то сессии все равно работают.
Majik13
Старожил
У нас походу немного разные понятия о надежности. Я смотрю с точки зрения сохранения информации клиента (донесения ее до сервера), а не с точки зрения использования кем-то его логина-пароля.
С моей точки зрения ХТТП - послал один раз и ты в системе. Куки с той же точки зрения менее надежны. Вот о чем я говорил.
А выход из системы - это уже другой разговор.
P.S. Кстати, в этом случае:
С моей точки зрения ХТТП - послал один раз и ты в системе. Куки с той же точки зрения менее надежны. Вот о чем я говорил.
А выход из системы - это уже другой разговор.
P.S. Кстати, в этом случае:
под дополнительной работой подразумевались скрытые поля в формах, чтобы передавать дальше айди сеанса? Если страниц много, надо же айди на каждую передавать.. или линки вручную писать.
zmc
Участник
Думаю, что виноваты в этом не плохие куки, а плохие программистыMajik13":252k3p5v сказал(а):
Тут спорить трудно: нет программирования, нету и кукMajik13":252k3p5v сказал(а):
Кстати, по поводу твоего предыдущего сообщения: пароли в апаче шифруются с помощью стандартной C-шной функции crypt(), которая есть и в perl'е, и в php. Так что генерить файлы с паролями для апача на лету можно без проблем.Чистая правда. В каждом скрипте надо ставить кусочек кода, который бы проверял эту куку.Majik13":252k3p5v сказал(а):
И это тоже правда. Однако время действия куки ты выбираешь сам, ставь хоть на три годаMajik13":252k3p5v сказал(а):
Правда все эти три года любой человек с этого броузера сможет ходить на сервер под твоим логином не вводя пароля Все-таки, на мой взгляд, основное и практические единственное преимущество http-авторизации в том, что она не требует практически никаких усилий со стороны создателя сайта.Majik13":252k3p5v сказал(а):
zmc
Участник
Да, я имел в виду надежность "второго рода".Majik13":23cpr1kt сказал(а):
Но тем не менее, механизмы кук и http-авторизации с технической точке зрения практически одинаковы.
В случае с куками: сервер отправляет броузеру куку, тот её запоминает и начинает включать её в каждый http-запрос, отправляемый серверу (или, точнее, к определенным страницам сервера, которые прописаны в параметрах куки).
В случае с http-авторизацией: в первый раз получив ответ со статусом 401 (Unauthorized) от сервера, броузер запрашивает логин/пароль у пользователя, опять-таки запоминает их, и начинает отправлять их в заголовках http-запросов к серверу.
И как тут можно говорить о большей надежности одного или другого способа "донесения информации до сервера", непонятно.
Именно так, программисту надо позаботится о приписывании ID сессии ко всем ссылкам на страничках, отдаваемым залогиненому посетителю, чтобы не потерять его сессию. Не знаю, что ты имел в виду под словами "вручную писать", просто скрипт, который рисует странички на сайте, станет чуть-чуть посложнее, и все.Majik13":23cpr1kt сказал(а):
Majik13
Старожил
1. Ок. Понял, я просто не знал, что механизм ХТТП также передает параметры в тех же запросах (хотя как же еще) =) Я не программист, просто меня этот разговор задел за живое, так как в дипломной работе пришлось с этим (авторизацией) столкнуться... Но разница в приведенных тобой примерах опять же упирается в возможность установки куки... Ладно, неважно.
2. Имел в виду что-то в духе
link?sess_id=%s
Ок. Спасибо, некоторые вещи прояснили, да я и не претендую на роль абсолютной истины ни в каких утверждениях, просто высказываюсь на основе своих знаний и опыта. Если есть еще что сказать интересного, welcome Мне по-крайней мере интересно.
) =) Я не программист, просто меня этот разговор задел за живое, так как в дипломной работе пришлось с этим (авторизацией) столкнуться... Но разница в приведенных тобой примерах опять же упирается в возможность установки куки... Ладно, неважно.2. Имел в виду что-то в духе
link?sess_id=%s
Ок. Спасибо, некоторые вещи прояснили, да я и не претендую на роль абсолютной истины ни в каких утверждениях, просто высказываюсь на основе своих знаний и опыта. Если есть еще что сказать интересного, welcome
Мне по-крайней мере интересно.Разъяснения:
form в скрипте, method=post, а теперь внимание вопрос: как убедиться, что данные, полученные скриптом, переданы именно из этой формы и именно методом post, а не получены, скажем, из адресной строки?
Для чего это? Если скрипт принимает данные из адресной строки как свои родные, то вся система авторизации и шифрования идёт прахом, потому что пароль можно подобрать, генеря url автоматически. По-моему так.
form в скрипте, method=post, а теперь внимание вопрос: как убедиться, что данные, полученные скриптом, переданы именно из этой формы и именно методом post, а не получены, скажем, из адресной строки?
Для чего это? Если скрипт принимает данные из адресной строки как свои родные, то вся система авторизации и шифрования идёт прахом, потому что пароль можно подобрать, генеря url автоматически. По-моему так.
A
Anonymous
подкиньте скрипт: есть набор сообщений, надо чтобы из них появлялось выбранное случайным образом.
A
Anonymous
помогите пхп под апаче 1.3.27 поставить... все "пакеты" включающие пхп скл и т д вызывают ошибку при инсталляции
