|
|
|
|
|
для: oliss
(26.03.2010 в 13:48)
| | Спасибо | |
|
|
|
|
|
|
|
|
для: Trianon
(26.03.2010 в 03:45)
| | Понятно. А в чём фишка https? | |
|
|
|
|
|
|
|
для: sasha1133
(26.03.2010 в 01:42)
| | Плохо тем, что механизм идентификации сессии разрабатывался не для задач аутентификации, преследует совершенно иные цели и поэтому в рассматриваемом применении имеет изъяны.
Один из них (связанный с передачей SID в GET-параметрах скрипта) Вы уже подметили.
А кукис можно поставить и более изощренный.
Хотя для жестких ситуаций все равно придется поднимать https | |
|
|
|
|
|
|
|
для: oliss
(26.03.2010 в 02:39)
| | чем же легче, если и в том и в том случае куки? И всё таки , как можно улучшить защиту? Проверять ip, версию браузера и тп (помимо сессий)? | |
|
|
|
|
|
|
|
для: sasha1133
(26.03.2010 в 01:42)
| | Вот этот самый идентификатор намного легче увести ( хотя, как реализована защита скрипта ), чем куку с вашего компьютера | |
|
|
|
|
|
|
|
для: Trianon
(26.03.2010 в 00:57)
| | Ключ к сессиям по умолчанию хранится в тех же куках. Только как вариант когда куки выключены - передаются в ссылках и скрытых полях форм. Тем самым имея куку с идентификатором сессии, доказываем серверу, что клиент не верблюд (или наоборот - именно верблюд =) ). Чем плохо? | |
|
|
|
|
|
|
|
для: sasha1133
(26.03.2010 в 00:47)
| | А то, что аутентификация - процесс доказывания серверу клиентом, что он не верблюд.
Как Вы сессиями хоть что-то докажете, если они не у Вас, а у сервера? | |
|
|
|
|
|
|
|
для: oliss
(25.03.2010 в 17:30)
| | Это я знаю, кэп) И что с этого? | |
|
|
|
|
|
|
|
для: sasha1133
(25.03.2010 в 17:27)
| | Самое главное вы пропустили: сессии живут на сервере ,а куки на клиенте
Делайте выводы. | |
|
|
|
|