Есть небольшой сайт. Сушествует следующая проблема - нужно на нем авторизироваться. Пока я просто таская логин и пароль в строке адреса (то есть страницы выглядят page.pl?login=$login&password=$password).Как Вы понимаете - это не есть очень хороший способ. Но проблема в том, что я не знаю, как можно сдлелать лучше. Если не слжно, скажите, пожалуйста, как нужно грамотно делать авторизацию.....
а на сайте твои скрипты работабт?
самое простое, если скрипты на сайте обрабатывают и метод POST, использовать его. смотри, напр. модуль HTTP.
>а на сайте твои скрипты работабт?
>самое простое, если скрипты на сайте обрабатывают и метод POST, >использовать его.
>смотри, напр. модуль HTTP.Честно говоря, не вполне тебя понял...
Сайт написан полностью мной, то есть скпритвы все мои (соответственно я могу их как угодно править и что угодно с ними делать)
Скримты на сайте могут отрабатывать и ПОСТ (имхо для param() нет никакой разницы, как переданы значения Post-ом или Get-ом).
Исключительно метод POST я не могу исползовать, так как необходимо ходить по сайту не только с помощью кнопок submit, но и по ссылкам (а через простую ссылку, насколько я знаю POST-ом передать нельзя).
Модуль HTTP достаточно большая штука. Что конкретно нужно мне смотреть, что подходает под мои запросы?
Сорри, если несколько невнятно ответил, просто я не очень понял твой ответ...
а я не совсем понял, что ты хочешь сделать.
скрипт, который берёт страницы с сайта и при необходимости аутентифицируется?
или, нужно сделать страницы, с которых бы пользователь прозрачно переходил бы на другие защищённые страницы?
>а я не совсем понял, что ты хочешь сделать.
>скрипт, который берёт страницы с сайта и при необходимости >аутентифицируется?
>или, нужно сделать страницы, с которых бы пользователь прозрачно >переходил бы на
>другие защищённые страницы?Извини, пожалуйста, действительно не очень грамотно все рассказал. Дело в том, есть несколько страниц. Нужно, чтобы человек спокойно мог перемещаться по страницам (есть менюха с сылками), но при этом каждая страница занала, авторизирован ли он или нет (То есть нужно чтобы в начале он ввел свой логин и парль, а потом спокойно мог лазить по страницами без ввода пароля.... )
Сейчас у меня это сделанно и работает. Но как мне кажется это сделанно не очень хорошим способом. Я все время передаю логин и парль в строке адреса (то есть все ссылку у меня выглядят page.pl?login=vasya&password=pupkin)
Как можно сделать более грамотно все это?
Надеюсь, что на этот раз я смог грамотнее все это объяснить.....
если страницы в пределах одного сайта, можно использовать механизм сессий.
для Perl-а должны быть соотв. библиотеки.
или можно соорудить что-то своё на основе cookies или случайных шифрованых параметоров в URl-ах.
> если страницы в пределах одного сайта, можно использовать механизм сессий.
> для Perl-а должны быть соотв. библиотеки.Это интересно. Можно поподробнее. Типа, man что ? :)
А то пока есть мысль, при логине генериться средствами БД случайное число, загонять его в MD5-хэш, сохранять этот хэш в таблице пользователей и отправлять в виде куки клиенту. Всё хорошо, но придется при каждом http-запросе делать два sql-запроса к базе - первый к таблице пользователей для сравнения хэшей и второй уже к данным.
Может есть более простой способ проверки валидности ключа ?
>> если страницы в пределах одного сайта, можно использовать механизм сессий.
>> для Perl-а должны быть соотв. библиотеки.
>
>Это интересно. Можно поподробнее. Типа, man что ? :)
>
>А то пока есть мысль, при логине генериться средствами БД случайное число,
>загонять его в MD5-хэш, сохранять этот хэш в таблице пользователей и
>отправлять в виде куки клиенту. Всё хорошо, но придется при каждом
>http-запросе делать два sql-запроса к базе - первый к таблице пользователей
>для сравнения хэшей и второй уже к данным.
>Может есть более простой способ проверки валидности ключа ?
Извини, что-то я не поспеваю за твой мыслю....
Юзер на странице вводит логин/пароль - он отправляется на сервер. Проверяется с действетельными значениями, которые лежат в базе. Если все в порядке, генериться на стророне сервера какое-то значаение - передает его обратно клиенту - это ключ сессии. Все время даельше именно с помощью этого ключа происходит проверка валидности клиента.Я правильно Тебя понял?
Да. Правильно. Ключ ко всему прочему должен иметь срок действия, но это легко делается добавлением текущего времени при апдейте (можно использовать функции самого сервера) и усливием выборки, вида " where key='ключ' and login='логин' and (now()-valid_date) <= 'срок_действия_в_понимаемом_базой_формате' ". Если вернется 0 записей, то либо клиент не авторизован, либо истек срок действия ключа.PS. Попутно можно привязаться еще и к IP-адресу клиента :)
>Да. Правильно. Ключ ко всему прочему должен иметь срок действия, но это
>легко делается добавлением текущего времени при апдейте (можно использовать функции самого
>сервера) и усливием выборки, вида " where key='ключ' and login='логин' and
>(now()-valid_date) <= 'срок_действия_в_понимаемом_базой_формате' ". Если вернется 0 записей, то либо клиент
>не авторизован, либо истек срок действия ключа.
>
>PS. Попутно можно привязаться еще и к IP-адресу клиента :)Пожожди. Ключ - это у нас какая-то страшная строка (рандом на стороне сервера, обратотанный Md5) мы с помощью нее просто вычленияем сессию. Как можно в нее запихнуть еще какие-то полезные данные? Мы же ее не обрабатываем мы просто проверяем, равна ли она той, котороая лежит на сервере?
ЗЫ Приявязка к айпишнику - это саоме простостое что может быть. Это уже у меня сделанно.
Так это... По какому значению ты будешь строить MD5-хэш ? Можно ведь не только по паролю. Вот привязка хэша в SQL-запросе к рандому, логину, паролю и IP-адресу с использованием БД Postgres:... md5(random() || 'login' || 'a.b.c.d' || 'passwd') ...
>> если страницы в пределах одного сайта, можно использовать механизм сессий.
>> для Perl-а должны быть соотв. библиотеки.
>
>Это интересно. Можно поподробнее. Типа, man что ? :)
>
>А то пока есть мысль, при логине генериться средствами БД случайное число,
>загонять его в MD5-хэш, сохранять этот хэш в таблице пользователей и
>отправлять в виде куки клиенту. Всё хорошо, но придется при каждом
>http-запросе делать два sql-запроса к базе - первый к таблице пользователей
>для сравнения хэшей и второй уже к данным.
>Может есть более простой способ проверки валидности ключа ?Рекомендую загонять данные в BerkeleyDB тогда со скоростью обращения к DB проблем не будет.
Не хотелось бы использовать разношерстные базы
сессии позволяют создавать переменные(сессионые), кот. живут в рамках одной сессии пока она не будет закрыта. управлять открытием/закрытием можно из скриптов. идентификатор сессии (с которым связаны сессионные переменные) для текущего подсоединения хранится напр. в cookies или записывается в виде параметра в URL.
сценарий приблизительно такой: человек заходит на страницу, для него создаём новую сессию, далее он предоставляет логин и пароль, если они подходят, создаём в текущей сессии переменную, что в этой сессии человек прошёл аутентификацию, и дальше проверям в нужных местах наличие такой переменной.>А то пока есть мысль, при логине генериться средствами БД случайное >число, загонять его в MD5-хэш, сохранять этот хэш в таблице пользователей >и отправлять в виде куки клиенту
это и будет приближение к тому, как реализуютя сессии.
лучше взять что-то готовое, отлаженное и более функциональное.к сожалению, в Perl-е сессиями я не пользовался,
т.к. использую для программирования для WWW PHP и ещё Zope.
и там и там есть встроенная поддержка сессий.
для Perl-а можно использовать напр. CGI::Session.
> это и будет приближение к тому, как реализуютя сессии.Я так и понял :)
> лучше взять что-то готовое, отлаженное и более функциональное.
Потому и спросил.
> для Perl-а можно использовать напр. CGI::Session
Спасибо. Посмотрим.
>если страницы в пределах одного сайта, можно использовать механизм сессий.
>для Perl-а должны быть соотв. библиотеки.Страницы в пределах одного сайта. Что такое механизм сессий и где в нете про это можно почитать?
>или можно соорудить что-то своё на основе cookies или случайных >шифрованых параметоров в URl-ах.
Я понимаю, что как раз это и нужно использовать, но очень интересны именно конкретные алгоритмы (или ссылки на них)....
Заранее большое спасибо!
А почему не использовать стандартную Апачевскую авторизацию ?тогда страницы будут видны только авторизовавшимся пользователям, а их
логин всегда доступен в переменной окружения.
>А почему не использовать стандартную Апачевскую авторизацию ?
>тогда страницы будут видны только авторизовавшимся пользователям, а их
>логин всегда доступен в переменной окружения.Да? Здорово! Спасибо большое, я не знал.... Да. Это вариант, но к сожалению этот вариант не подходит.... =( Просто это вываливающееся окно, вызавает гораздо больше паники у юзера, чем просьба ввести логин пароль на сайте....
>Сайт написан полностью мной, то есть скпритвы все мои (соответственно я могу
>их как угодно править и что угодно с ними делать)
>
>Исключительно метод POST я не могу исползовать, так как необходимо ходить по
>сайту не только с помощью кнопок submit, но и по ссылкам
>(а через простую ссылку, насколько я знаю POST-ом передать нельзя).
>А чем не подходит такая ссылка для submit? Можно и проще 1 строкой.
unction submitForm()
{
document.form1.submit();
}
</script><form name="form1" method="post" action="anotherPage.asp">
<a href="javascript:submitForm();">
</form>
Это немного know how, почему-то мне думается. С первого взгляда
достаточно просто, но если присмотреться, то сложностей хватит.В первом приближении можно полагаться на использование cookies.
Если речь идет о программировании на Perl, то очень целесообразным
будет использование CGI.pm. man-страница (man CGI) кроме описания
модуля, представляет собой очень полезное введение в CGI per se.Сложность с cookies в том, что они не всегда будут поддерживаться
на стороне пользователя, некоторые их просто отключают (меньшинство,
кстати, наверное).Рекомендую почитать про то, как реализован механизм "сеансов" в PHP,
и т. д.. И вряд ли стоит писать свой код для этого./poige
--
http://www.i.morning.ru/~poige/