Как лучше авторизовать пользователя

[13th]

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

Собственно вопрос такой :
Что лучше авторизация посредством .htaccess и .htpswd ? Или же стандратно посредством формы и полей логин пароль?
Напомню, что разговор о веб приложение на рнр

И опять же, если выбрать первый вариант, то как поймать данные об авторизованном пользователе для системы рнр скриптов.



Жду аргументов!

Убедительная просьба - троллей проходить мимо, не надо писать типа "а я юзаю java, python и у меня всё ништяк." и шуток.

[Человек_Борща]

Авторизация через форму хороший вариант т.к. работа с БД куда шустрее чем с ФС(ISP - ПУ управления сайтом - не плохой пример, когда БД - файл на харде, а не таблицы в БД. Панель хорошая но и бзики у неё тоже ничего).
Вот мои рассуждения:
Допустим есть глобальный проект ориентированный во все стороны.

Кто нам нужен?
Управляющая категоря
Служащая категоря
Посетители

Управляющая категория:
1. Администраторы
1.а. Основатель(модерирует весь форум)
1.б. управляющий(Доверенное лицо, полновправно получевшее доступ в ПУ и управляет веренной ему частью форума).

Служащие-управляющие-посетители:
2. Модераторы:
2.а. Старший модератор(Модерирует категорию и его разделы)
2.б. Младший модератор(Доделывает то, что не доделал старший, в той же ветке)

3. Пользователь
3.а. Ньюс-мейкер(Форуму нужны новости/обновления).
3.б. Привелегированный пользователь(Допущен куда-либо, закрытые разделы и тд.)
3.в. Рядовой юзер.
2.г. "Рекламер"[Да, это смешно.](Занимается ползаньем по др. форумам и рекламирует нас).


Все зависит от размера проекта. И конечно же не следует "жалеть", и доступы давать прямолинейно и жестко-фиксировано.

[13th]

Скорость и надежность работы с БД по сравнению с файлами htaccess & htpswd проигрывает. Да и безопность у стандартный методово авторизации куда выше.

Остается вопрос - сервер понял ,что можно конкретно этого пользователя пускать к опеределенной директории на сайте.

А как системе дать понять какой именно пользователь зашел.


К чему вообще всё это - в своем новом релизе системы я хочу свести роль БД к минимуму , то есть только хранение данных по пользователям. Авторизация будет происходить без неё (хотелось бы ).

Как я собираюсь организовать процесс ?
Загружаем, если нет файла конфига , с БД всех пользвоателей, пишем в файл и в htpswd пароли , которые шифруются для такого рода авторизации.
Далее сервер авторизует пользователя и скрипт (вполне возможно из глобальных переменных) узнает кто к нему зашел. А дальше всё просто на основе zend acl (очень крутое решение) расписываем права по группам.

Интересно мнение - какие проблемы могут меня поджидать и чем это лучше/хуже стандартного решения

[Человек_Борща]

http://designn.org.ua/blog/ru/13.htm и http://www.php.su/articles/?cat=apache&page=005

Интересно мнение - какие проблемы могут меня поджидать и чем это лучше/хуже стандартного решения

2-n одновременных регистраций, вызовут эпичный фэил со стороны системы т.к. файл ужен занят,и перезаписать/изменить его нельзя.

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

Из этого вытекает, что ваша файловая БД будет ооочень большим тормазом.

[Smitt&Wesson]

Сообщение от Человек_Борща

http://designn.org.ua/blog/ru/13.htm и http://www.php.su/articles/?cat=apache&page=005

Интересно мнение - какие проблемы могут меня поджидать и чем это лучше/хуже стандартного решения

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

Из этого вытекает, что ваша файловая БД будет ооочень большим тормазом.

В дополнение замечу, что в БД очереди уже организованы.
Я не думаю, что людей допущенных к модерированию у Вас будет больше десятка. Незачем морочить себе голову всякими .htacchess...
Используйте его по-прямому назначению - локальная конфигурация сервера, а БД по своему прямому назначению - хранение структурированных данных о пользователях.

[13th]

ага, понял. всем спасибо