Forum Webscript.Ru
Программирование => PHP => Тема начата: Tryapkonator от 20 Мая 2005, 18:06:38
-
Как правильно организовать авторизацию на сайте? Всмысле как это сделать оптимально для сервера, с наименьшей нагрузкой? При использовании кукисов, нужно минимум оин лишний запрос на страницу для проверки логина и пороля. Использование сессий, как мне кажется, тоже не верно. Т.к. помим запроса к БДЖ, который необходим (сверка логина и пороля) будут еще писаться файлы сессий на сервак. 403 заголовок и опять коннект к БД на каждой странице.... А можно как-то проще это сделать?
-
http://httpd.apache.org/docs/howto/auth.html#basic
-
Да, ошибся, не 403, а 401. Одна малина у БД придется спрашивать. Тогда какая разница где зхронить данные, в кэше браузера или куках поситителя.
-
Tryapkonator:
у БД придется спрашивать
Зачем? При такой авторизации данные хранятся в файле. Или у вас есть база с таблицей пользователей, и вы хотите оттуда цеплять данные?
-
Пользователей 67000....
-
Сурьезно. Попробуйте вот это: http://www.diegonet.com/support/mod_auth_mysql.shtml
-
mod_auth_db
mod_auth_mysql
mod_auth_pgsql
на выбор :)
-
Цепляется. как я понял, модулем к апачу? Сейчас почитаю, спасибо. Но тему, прошу, пока не закрывать... Вдруг что-то не пойму или будут еще какие предложения.
-
Tryapkonator:
ри использовании кукисов, нужно минимум оин лишний запрос на страницу для проверки логина и пороля
Можно развернуть эту мысль поподробнее?
-
Цеплять модули не очень хочется. Придумал кое-что проще. При заходе на страницу проверяются кукисы. Если их нет - выводится форма авторизации. После авторизации создается сессия (ну или просто файл с данными) а в куку пишется логин и идентификатор сесии (имя файла). При следующем заходе снова проверяется наличие куки. Если таковой нет - опять форма. Если есть, топодгружается сессия по ее идентификатору из куки (инклудится файл с именем из куки), сверяется логин из сессии (файла) с логином в кукисах и если все нормально, пользователю отдается страница. Если нет - уничтожается кука и сессия (файл) и выдается форма регистрации.
Единственная запара - не очень я сессии люблю. незнаю как они устроены, насколько быстро работают. Например, что быстрее выполнится, проверка существования сесии и ее подключение, либо проверка на наличие файла и его инклуд, при том что файл содержит что-то вроде
$login=\'Tryapich\';
$pass=\'12345\';
?>
и так далее. Где-нибудь есть русская информация на тему быстродействия сессий и быстродействия include() и file_exists()?
-
Использование сессий, как мне кажется, тоже не верно. Т.к. помим запроса к БДЖ, который необходим (сверка логина и пороля)
С какой радости?
Croaker, ThE0ReTiC, какой смысл отвечать на вопрос, если видно, что человек задаёт его от чудовищного невежества?
-
Придумал кое-что проще
создается сессия а в куку пишется логин
феерично.
-
Где-нибудь есть русская информация на тему быстродействия сессий и быстродействия include() и file_exists()?
Нету нигде.
В силу полной бессмысленности вопроса.
не очень я сессии люблю. незнаю как они устроены,
Кто мешает узнать?
-
Почитал про сессии, действительно невежа. Вопрос снят, можете меня забанить =)
-
Хотя на самом деле это предубеждение что ограничить доступ можно только через 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 в месяц.
-
а не проще переписывать htpasswd?
-
Дык проще конечно, но еще один смысл такого безобразия в том, что получается прозрачная для пользователя авторизация - логин и пароль ему придется вводить только один раз в html форму, а по сети в заголовках каждого реквеста не будут передаваться настоящие логин и пароль ( это принимая во внимание что mod_auth_digest все-таки экзотическая вещь и все в основном юзают обычный mod_auth :)