Авторизация и аутентификация. Корректность алгоритма.

[4m@t!c]

Авторизация и аутентификация. Корректность алгоритма.

Необходимо сделать аутентификацию, а затем авторизацию для каждой странице на сайте.
Сразу оговорюсь. посетители пользуют куки, от тотального снифа защищать не надо. Необходимо проверять права доступа к странице и выдавать или не выдавать информацию посетителю. Исследуя форум по "аутентификация" и "авторизация" надумал такой алгоритм. Сейчас берусь за его реализацию. так как опыта нет, то был бы признателен. если бы Вы указали на ошибки и вобщем сказали корректность идеи.
Аутентификация
1. Клиент в форме передает login и пароль.
2. Происходит поиск в таблице аккаунтов - accounts.
3. Результат поиска возвращает ID аккаунта. Если возвращается «0», то пользователю сообщается о неверных данных и происходит авторизация незарегистрированного пользователя.
4. ID аккаунта проверяется по таблице посещений hosts. В таблице есть следующие поля: memberid(ID аккаунта), cookhash(значение куки-хеша), ip(REMOTE_ADDR), hostdate(дата последнего посещения).
4.1. Если строка с таким ID существует, то значения ее полей обновляются.
4.2. Если строки с таким ID не существует, то добавляется новая строка.
5. Клиенту устанавливается кука-хеш, а в переменные сеанса записывается ID аккаунта.
Авторизация
1. Проверяется кука-хеш на существование.
1.1. Если кука-хеш найдена, то происходит поиск в таблице hosts по куке-хешу и REMOTE_ADDR.
1.1.1. Если IP-адреса различны, то удалить соответствующую запись из таблицы. Пользователю присвоить минимальный уровень доступа.
1.1.2. Если IP-адреса совпадают, то выдать уровень доступа, соответствующий ID.
1.2. Если кука-хеш не найдена, то пользователю присвоить минимальный уровень доступа.

и еще вопрос по ходу. На сколько опасно записывать уровень доступа к странице в переменную сеанса. стоит ли это того, что бы лишний раз обратиться к БД и вытянуть по ID статус посетителя???

 

[Erise]

3. Результат поиска возвращает ID аккаунта. Если возвращается «0», то пользователю сообщается о неверных данных и происходит авторизация незарегистрированного пользователя.

А зачем незарегестрированного авторизовывать?

Можешь кинуть все права пользователя в сессию, предварительно взяв их из БД при авторизации этого пользователя.

 

[4m@t!c]

Автор оригинала: Erise
А зачем незарегестрированного авторизовывать?

Что бы выдать страницу с интерфейсом для незаргестрированного опльзователя. (Хм... может, я не понял вопрос???...)

 

[Erise]

Хорошо! А что ты имеешь ввиду здесь под словом "авторизация"?

 

[4m@t!c]

Автор оригинала: Erise
Хорошо! А что ты имеешь ввиду здесь под словом "авторизация"?

Без притензий на ИМХО, но по-моему разумению:
Аутентификация - это проверка соответствия субъекта и того, за кого он пытается себя выдать, с помощью некой уникальной информации - например, с помощью логина и пароля.
Авторизация - это проверка и определение полномочий на выполнение некоторых действий в соответствии с ранее выполненной аутентификацией.

 

[Erise]

А какие могут быть права у гостя?

 

[4m@t!c]

Гы-гы... Никаких или минимальные. Все зависит от конкретной страницы и действия. Действия осуществляются, как с помощью текущего интерфейса, так и в обход оного.
Мы отходим от темы. Если в процессе аутентификации не найден аккаунт, то чего тогда делать с посетителем???
З.Ы. Глупый вопрос

 

[Erise]

Да ничего не делать. Выдать ему, что такого логина не существует, и дать пинка.

 

[-=KPOT=-]

Re: Авторизация и аутентификация. Корректность алгоритма.

была аналогичная проблема решилась легко:
1- у каждого зарегистрированного юзера есть в таблице поле rule (числа 1,2,3 итд)
2- когда он авторизуется в сессию пишем переменную со значением данного поля
3- на каждой странице доступной зарегистрированным юзерам ставим в самом начале что то типа $min_rule=2; и когда к ней обращаемся проверяем если это число > чем в сессии (а там например 1) то типа прав у него мало и сюда мы его не пускаем

если к некоторой странице нужно допустить пользователей у которых права только 2 и 4 а остальным (1,3,5) болт то там механизм тотже тока проверка чуть другая не < или > а принадлежит массиву $min_rule или нет

Автор оригинала: 4m@t!c
На сколько опасно записывать уровень доступа к странице в переменную сеанса.

это как? наверное не в переменную а в сеанс?

 

[4m@t!c]

Есть ли смысл объеденить переменную, которая отвечает за уровень доступа и за интерфейс? наверное, все ж зависит от конкретного случая???
По-моему в авторизации нужно добавить проверку текущей сессии или срока давности хеш-куки.