Авторизация на сайте

[Tryapkonator]

Как правильно организовать авторизацию на сайте? Всмысле как это сделать оптимально для сервера, с наименьшей нагрузкой? При использовании кукисов, нужно минимум оин лишний запрос на страницу для проверки логина и пороля. Использование сессий, как мне кажется, тоже не верно. Т.к. помим запроса к БДЖ, который необходим (сверка логина и пороля) будут еще писаться файлы сессий на сервак. 403 заголовок и опять коннект к БД на каждой странице.... А можно как-то проще это сделать?

[Croaker]

http://httpd.apache.org/docs/howto/auth.html#basic

[Tryapkonator]

Да, ошибся, не 403, а 401. Одна малина у БД придется спрашивать. Тогда какая разница где зхронить данные, в кэше браузера или куках поситителя.

[Croaker]

Tryapkonator:
у БД придется спрашивать

Зачем? При такой авторизации данные хранятся в файле. Или у вас есть база с таблицей пользователей, и вы хотите оттуда цеплять данные?

[Tryapkonator]

Пользователей 67000....

[Croaker]

Сурьезно. Попробуйте вот это: http://www.diegonet.com/support/mod_auth_mysql.shtml

[ThE0ReTiC]

mod_auth_db
mod_auth_mysql
mod_auth_pgsql

на выбор

[Tryapkonator]

Цепляется. как я понял, модулем к апачу? Сейчас почитаю, спасибо. Но тему, прошу, пока не закрывать... Вдруг что-то не пойму или будут еще какие предложения.

[Меняздесьдавнонет]

Tryapkonator:
ри использовании кукисов, нужно минимум оин лишний запрос на страницу для проверки логина и пороля

Можно развернуть эту мысль поподробнее?

[Tryapkonator]

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

Единственная запара - не очень я сессии люблю. незнаю как они устроены, насколько быстро работают. Например, что быстрее выполнится, проверка существования сесии и ее подключение, либо проверка на наличие файла и его инклуд, при том что файл содержит что-то вроде
$login=\'Tryapich\';
$pass=\'12345\';
?>
и так далее. Где-нибудь есть русская информация на тему быстродействия сессий и быстродействия include() и file_exists()?

[Меняздесьдавнонет]

Использование сессий, как мне кажется, тоже не верно. Т.к. помим запроса к БДЖ, который необходим (сверка логина и пороля)

С какой радости?


Croaker, ThE0ReTiC, какой смысл отвечать на вопрос, если видно, что человек задаёт его от чудовищного невежества?

[Меняздесьдавнонет]

Придумал кое-что проще
создается сессия а в куку пишется логин

феерично.

[Меняздесьдавнонет]

Где-нибудь есть русская информация на тему быстродействия сессий и быстродействия include() и file_exists()?

Нету нигде.
В силу полной бессмысленности вопроса.

не очень я сессии люблю. незнаю как они устроены,

Кто мешает узнать?

[Tryapkonator]

Почитал про сессии, действительно невежа. Вопрос снят, можете меня забанить =)

[Polar]

Хотя на самом деле это предубеждение что ограничить доступ можно только через mod_auth, а куки нужно проверять только из php. Никто не мешает по каждому событию удачного входа переписывать .htaccess - обновлять в нем список сессионных кук залогиненных пользователей и разграничивать доступ только на уровне апча :)  Например если есть mod_setenvif и ведется список идентификаторов активных сессий, можно сказать что-то вроде

Код: [Выделить]

ErrorDocument 403 "http://site.com/login_page.php"
SetEnvIf Cookie "061412e4a03c02f9902576ec55ebbe77" user_allowed
SetEnvIf Cookie "5705e1164a8394aace6018e27d20d237" user_allowed
Order Deny,Allow
Deny from all
Allow from env=user_allowed
тогда пользователей с этими двумя сессионными куками пустят в папку с таким .htaccess, а остальных перебросят на страничку для ввода пароля. То же самое можно организовать и через mod_rewrite, но нагрузка на сервер будет выше.
Смысл всего этого безобразия в том, что при большом числе пользователей и большом числе файлов в закрытой папке, событие добавления нового пользователя (удачного логина и обновления .htaccess) происходит в среднем в 80-150 раз реже, чем событие запроса чего-либо из защищенной папки. И php скрипт запускается во столько же раз реже. А вероятность 500-й ошибки от поступления запроса в момент когда .htaccess еще не закончил перезаписываться очень маленькая - у меня на одном сервере с постоянно висящими 80-100 онлайновыми пользователями это случается в среднем раза 3 в месяц.