Приветствую. Я пытаюсь сделать авторизацию. 
Делается это скорее из любопытства, чтобы разобраться, поэтому оставим вопрос "а нафига?" :)

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

То есть скрипт авторизации:
- определенному айпишнику выдает сессию, 
- сессия + пароль накрываются мд5, хэш отсылается на сервер, 
- сервер находит юзера и пароль в базе (пока что в качестве базы у меня просто текстовый файлик выше www-рута), 
- делает такой же хэш из пароля и сессии, которую он выдал айпишнику, 
- сверяет одно с другим, решает как быть дальше.
- если всё ок, то хэш (сессия+пароль), логин и время визита складываются в куку

А скрипт аутентификации 
- читает куку
- сверяет айпишник, хэш, и время
- если что-то не так, выкидывает на скрипт авторизации

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

1. Еще какие-нибудь проблемы с таким вариантом есть?

2. Подскажите, как это все организуется на сервере?
Я не совсем понимаю, как добиться того, чтобы при обращении к чему-либо в директории с движком вызвался скрипт аутентификации... 
Попробовал всё реврайтить на скрипт логина - но сервер уходит в астрал, когда я из своих скриптов пытаюсь при помощи LWP зачитать хтмл в той же папке. Получается рекурсивный реврайт. :) Как быть?

Я вам опишу очень простую схему которую я применяю, и считаю ее одной из самых удачных 

Схема основана на доверии третьему лицу, где в качестве доверенного сервера выступает email.

1: при попадании человека на защищаемую часть ресурса, если он не обнаруживается в списке открытых сессий, ему выдается страница входа. (как это сделать я дам пример позже)
2: страница входа это одно поле, с просьбой ввести email человека.
3: при нажатии ввод нам отправляется его адрес, 
4: мы проверяем его мыло у себя, то есть он у нас зарегистрирован и это мыло мы проверяли при регистрации и доверяем ему.
5: если его мыло нашлось у нас в списке... то мы генерируем MD5 хеш для сессии и для куки. Куку ставим ему, а хеш сессии отправляем на мыло. И при удачной отправке выдаем страницу с подтверждением и просьбой проверить мыло.
Также куку, хеш сессии и его IP сохраняем у себя в базе с пометкой что вход не произведен и временной меткой истечения.
6: человек заходит на сервер доверия  тоесть проверяет собственное мыло и переходит по сгенерированной ссылке.
7: Мы его пускаем только в случае если совпали все составляющие... кука, хеш ссылки, IP и еще не истекло время действия сессии.
8: мы ставим метку что вход на эту сессию произведен, генерируем новую куку, ставим ему и сохраняем в базе с новым временем истечения сессии.
9: при генерации любой страницы мы генерируем новую куку и продлеваем время.
10: этим мы добиваемся того что время сессия у нас истечет отсчитывая с момента последнего посещения... да и повторный вход по тойже ссылке станет невозможен.

Почему я предпочитаю этот способ, потому как не нужно связываться со всякими логинами паролями, и т.д. достаточно email. Это удобно посетителю, ему не нужно помнить еще один пароль на вход, достаточно одного единственного на собственное мыло  А нынче оно у всех есть...

Это способ хорошо подходит для ресурсов на которые редко нужно логиниться, у меня это реализовано для админки на уровне ядра системы, как самый базовый вариант, и мыло береться и главного конфига, а туда писалось ручками при установке самим админом... адресов там всего 2-3, на всяк случай  Сессия у меня тоже четк задана, всего 10 минут...
Нефиг ядро мучать больше, обычно там всего одну галочку поставить или убрать нужно...

Этот способ очень хорош, для форумов, или любых частопосещаемых ресурсов. Тогда сессию лучше юзать в базе и ставить куку к примеру на полгода, и в базе такое же время прописывать и не учитывать IP, а только наличие куки...

Как правило особо секретного на фруме нифига нет, и привязываться еще к IP нет нужды...

Как производиться внутренний переход, то тоже просто. У меня не жменя скриптов, а всего один скрипт для всего сайта, в зависимомти от праметров он выводит необходимую страницу... поэтому никаких редиректов не нужно. Редирект у меня на самого же себя, после успешной регистрации когда я уже перебрасываю человека на страницу с защищаемой информацией...

Кстати запомнить этот адрес, чтобы человека туда отправить сразу, тоже рекомендую в базе в сессии. Тогда человек после корректного входа окажется на странице на которую хотел попасть изначально, и самому исхать не нужно будет... ну это уже так сервис для удобства 

интересный вариант, спасибо. :)

но я хочу сейчас понять как всё это делается в класическом варианте. :)
я уже более-менее разобрался с самим скриптом, но не понимаю, как на сервере всёэто грамотно расставить. :)

> Кстати запомнить этот адрес, чтобы человека туда отправить сразу, тоже рекомендую в базе в сессии. Тогда человек после корректного 
> входа окажется на странице на которую хотел попасть изначально, и самому исхать не нужно будет... ну это уже так сервис для удобства 

это я сделаю обязательно.
можно в скрипте аутентификации сориентироваться по REQUEST_URI.
эту переменную окружения вроде сервер сам формирует при редиректе.

В классическом варианте это приблизительно так....
Сессия - понятие относительное, это просто способ каким-либо способом идентифицировать клиента, и сохранять какие-то данные между запросами клиента к серверу. Обычно сессия имеет ограничение по времени.

У сессии есть уникальный идентификатор. Сессия должна гдето храниться.  для этого может быть использованы или куки для хранения параметров сессии на стороне клиента, и нужно предусмотреть хранение защищенных данных о клиенте, но которые клиент изменять права не имеет, эти данные храняться на сервере и соответствуют ID сессии.

Зачастую у клиента храниться только кука, все остальные данные соответствующие этой куке и соответственно этой сессии храняться в параметрах сессии на сервере. Иногда, когда куку клиент не принимает, ID сессии включают в URL.
Тогда вы видите в строке броузера что-то типа такого http://examole.com/?CGISESSION=ertwqfewqfhu79813465hoip234.
И идентификатор такого типа приписывается к каждой ссылке на странице, чтобы сервер мог однозначно поставить соответствие сессии.

Это как один из вариантов.

Но хранилище для однозначного идентифицирования клиента и сессии на сервере быть должно... не рекомендуется выносить все данные в куки, иначе можно сильно лохонуться  хотя на некоторых сайтах чего только не увидишь 

На сервере это можно организовать по разному... хранить сессию в базе данных или просто в файлах, или в одном файле.

CGI::Session помогает такое организовать. Он в зависимомти от параметров настрйки, может сохранять сесионные данные просто в файле, на каждую сессию свой файлик типа session897986, в котором хранит сериализованные Dumper'ом данные. Только права на запись в каталоге сессий ему нужны для этого.
Может хранить в куках на стороне клиента, что я не рекомендую  разве что шифровать... 
А может использовать DBI, тоже настраивается достаточно гибко.

Можете изучить примеры, ну и вопросы задавайте... Я его немного помучал пока писал драйвер для хранения сессий в базе через свой уровень абстракции 

Спасибо, только базовая инфа у меня есть, механизм я вроде понял. :)
Я при размещении всего этого на сервере путаюсь.

Сделал так:

— есть папка, в которой лежат защищенные страницы

— в этой папке есть .htaccess, в нём прописано:

    Options -Indexes

    RewriteEngine on

    RewriteRule index.html /cgi-bin/login.pl

    RewriteCond %{REMOTE_ADDR} !айпи_моего_сервера
    RewriteRule страница1 /cgi-bin/движок_страницы_1.pl

    и т. д., страниц таких три. то есть, при обращении к странице не от моего сервера, для страницы вызывается скрипт.

— движок_страницы.pl вызывает скрипт аутентификации, если аутентификация пройдена, зачитывает соответствующую страницу, генерит что нужно, и выдает её. если нет, выдает /cgi-bin/login.pl

Нормально так?

Боюсь Вы не с того начали 

Реврайт обычно настраивается в самом конце, на готовые скрипты...

Второе, он не на каждом хостинге доступен, если у вас нет жесткой привязки к хостеру, то я бы тоже пока реврайт оставил в покое, а добился нормального функционирования системы...

И третье, не зная что делает ваш login.pl и другие скипты аутентификации тяжело сказать, нормально ли 

login.pl проверяет куки и если сессия есть+еще не устарела, выдает индекс. в противном случае выдает форму для логина.

> Реврайт обычно настраивается в самом конце, на готовые скрипты...

я уже дважды сказал - я написал сами скрипты :)
написал скрипт, выдающий форму и генерящий сессию, и написал скрипт, проверяющий это всё.

я может непонятно спросил - с самими скриптами у меня проблемы нет.
теперь разбираюсь как это сложить на сервере.
есть же масса вариантов.  :omg 

ладно, я вроде прозрел, вечером все допишу, наверное :)

Это сообщение отредактировал(а) Верлиока - 22.1.2007, 21:49