Re: SingleLogon аутентификация?
Artem Chuprina
GP> Здравствуйте!
GP> Что-то никак не получается придумать механизм для сабжа. Что конретно нужно:
GP> есть главная страница сайта, доступная всем, и в ней есть красивая формочка для
GP> ввода логина и пароля зарегистрированными пользователями. Допустим, передал я
GP> логин с паролем серверу
GP> Вопрос 1: получается, что пароль будет передаваться открытым?
GP> , там скрипт сравнил их с содержимым штатного htpasswd
GP> Вопрос 2: htpasswd приходится держать без htaccess, иначе при входе на закрытый
GP> раздел помимо красивой формы с главной страницы юзеры увидят стандарное окно
GP> ввода логина/пароля?
GP> и, если есть такой юзер, сформировал ему в ответ некую страничку.
GP> Главный вопрос: раз я хочу избавиться от стандартных окон путём неиспользования
GP> htaccess, то как мне уберечься от прямого вызова скрипта из закрытой части
GP> сайта? У меня уже есть кучка скриптов, они все работают через штатную
GP> атентификацию. Понятно, что можно в закрытой части оставить только 1 скрипт, в
GP> начале которого проверять логин/пароль, но склеивать в одну кучу 50 скриптов -
GP> как-то неправильно, имхо.
Классика жанра - криптованная кука. Подробно расписано было в книжке
http://www.modperl.com/. Тебя интересует 6 глава, она там даже в
онлайне. Собственно модперловых особенностей там почитай что и нет. В
любом случае - use the brain, Luke.
Да, если что - здесь по умолчанию веб-сервером считается апач :-)
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru
Hажатие на кнопку "Запомнить пароль" не поможет ВАМ запомнить пароль.
-- http://bash.org.ru/quote.php?num=101483
Victor Wagner
wrote:
GP> Здравствуйте!
GP> Что-то никак не получается придумать механизм для сабжа.
GP> всем, и в ней есть красивая формочка для ввода логина и
GP> пароля зарегистрированными пользователями. Допустим,
GP> передал я логин с паролем серверу
Да, если ты не воспользуешья HTTPS для передачи этой странички.
Впрочем, если ты готов пойти на то что для логина будет требоваться
javascript, то можно выдать вместе со страничкой какой-нибудь случайный
challenge, и на нем зашифровать пароль javascript-ом прямо в клиентском
браузере.
GP> , там скрипт сравнил их с содержимым штатного htpasswd
GP> Вопрос 2: htpasswd приходится держать без htaccess, иначе
GP> при входе на закрытый раздел помимо красивой формы с
GP> главной страницы юзеры увидят стандарное окно ввода
GP> логина/пароля?
Угу.
GP> и, если есть такой юзер, сформировал ему в ответ некую
GP> страничку.
GP> Главный вопрос: раз я хочу избавиться от стандартных окон
GP> путём неиспользования htaccess, то как мне уберечься от
GP> прямого вызова скрипта из закрытой части сайта? У меня уже
Hужно после проверки скриптом логина пароля сформировать пользователю
некоторую куку, которую и проверять во всех остальных скриптах.
Срок жизни этой куки, степень её защищенности от подделки и т.д.
варьируется в зависимости от степени паранойи и ценности защищаемых
данных. Hапример, можно позащищаться от перехвата куки злоумышленником
путем формирования её значения с использованием REMOTE_ADDR и
HTTP_USER_AGENT. Тогда если злоумышленник попытается украсть куку путем
перехвата траффика пользователя, то эта кука проверки не пройдет, если
злоумышленник пользуется браузером более другой версии или работает с
другого IP-адреса (последнее маловероятно, потому что куку красть скорее
всего будут в локальной сети из которой работает пользователь, а сеть за
NAT и все пользователи из этой сети с точки зрения твоего сервера имеют
один и тот же IP).
Можно также воспользоваться каким-нибудь стандартным модулем для
создания сессий, и проверять наличие активной сессии (которая тоже, как
правило, связана с наличием кук).
--
Спама бояться - в Usenet не ходить
Gennadij Pastuhov
VW> Можно также воспользоваться каким-нибудь стандартным модулем для
VW> создания сессий, и проверять наличие активной сессии (которая тоже,
VW> как правило, связана с наличием кук).
Спасибо большое всем за помощь!
... Jonny wanna live