Полная работа авторизации?

Посмотри на ЭТОМ сайте есть статьи по этой теме. Там все подробно описано.

Есть много разных способов и идеологий авторизации. Расскажу самый любимый мною алгоритм.

Итак. На сайте пользователь ввел логин и пароль и жмакнул на кнопку "Авторизоваться". РНР-скрипт получает введенные данные. К логину применяет фильтры отрезающие ключевые слова языка SQL и экранирует служебные символы. К паролю ничего не применяем кроме хэширования по алгоритму MD5.

Строим и выполняем SQL-запрос на поиск юзера с таким логином и таким хэшем пароля в таблице юзеров.

Не нашли - логин или пароль введены неверно, в авторизации отказано.
Найден? Значит создаем сессию.
Далее начинается самое интересное. Надо как-то пометить юзера что он залогинен. Многие делают это через сессии РНР. Лично я предпочитаю использовать для этого специальную таблицу сессий. Такая таблица содержит следующие поля: ID пользователя, время начала сессии, время последнего действия, время закрытия сессии, ключ сессии 1, ключ сессии 2.

РНР-скрипт генерирует два ключа сессии: два числа в промежутке от 1 до 2 в степени 32. Работа с числами удобна, тк каждый раз при получении таких ключей от юзера их можно легко избавить от попыток проделать SQL-инъекцию просто приведя к целому функцией intval(). Сохраняем в таблицу сессий запись: ID пользователя, время начала сессии, ключ сессии 1, ключ сессии 2. В куки юзеру пишем ID пользователя, ключ сессии 1, ключ сессии 2.

Теперь при каждой загрузке страницы получаем от юзера куки его браузера, из которых берем ID пользователя, два ключа, все это хозяйство приводим к int'у и ищем в таблице сессию с такими параметрами. Если нашли - в записи об этой сессии поле "время последнего действия" и выдаем юзеру ту информацию, которая нами задумана для авторизованных пользователей.

Минусы такой системы: сессии надо закрывать для чего необходимо использовать CRON, при большой посещаемости возникает большая нагрузка на БД, что в условиях виртуального хостинга может сказаться на количестве матюгов админов хостинга.

Плюсы: всегда знаем кто сейчас в онлайне и сколько их, имеем подробную статистику по длительности и количеству сессий каждого юзера, высокая стойкость к SQL-инъекциям (если конечно реализовано верно)

[QUOTE=zorkk]Минусы такой системы: сессии надо закрывать для чего необходимо использовать CRON, при большой посещаемости возникает большая нагрузка на БД, что в условиях виртуального хостинга может сказаться на количестве матюгов админов хостинга.
[/QUOTE]
CRON'ом можно подчищать минут через тридцать, а в остальное время сверяться с лишними записями на каждом заходе юзеря.
А в остальном - всё верно:)
только я всё-равно задействовал сессии php для этого. И так же в БД храню OID сессии и время.

2zorkk ИМХО для небольших проектов. Узнать кто он-лайн я могу и из папки session_path (что не только я делаю). Остальное... Дюк если мне нужна подробная статистика, то мне не лениво отдать немного денег и взять себе готовую систему для статистики или заюзать бесплатную, а вот такое отношение к БД... Представь если проект расчитан ~ на 8к запросов одновременно. Туда ещё эти приплюсуй. Цифры не с потолка. Взять ту же мамбу. 3,5к юзеров за раз - это не предел.

2shaelf
Иногда описанная мною схема единственно возможная. Например когда существует отдельный клиент, для которого сессия с сайтом общая. Используется в частности в некоторых видах онлайн игр.

И кстати - приведи пример проекта где 8000 запросов ежесекундно (ну кроме монстров вроде яндекса и гугла - там принципиально иные системы, в которых РНР места быть не может по определению).

Я привёл mambo.ru. Там php. Там одновременно туда сюда снуют довольно много народу (как я уже говорил, 3,5к далеко не придел). Теперь давай представим. Есть чат (php + oracle) + из-за переходов туда - сюда. Теперь посмотрим, сколько запросов нужно как правило для генерации одной странички. У меня сейчас на столе ТЗ лежит. Там в одном пункте указано, что расчитывать до 10000 запросов единоразово, язык PHP или ASP и БД Oracle. По поводу игр спорить не буду, т.к. их делать не доводилось, а выжимать что-то из пальца я не собираюсь, лишь понимаю, что данная система для большинства сайтов не применима из-за своей тяжести (неоправданная нагрузка на сервер).

[QUOTE=shaelf]...данная система для большинства сайтов не применима из-за своей тяжести (неоправданная нагрузка на сервер).[/QUOTE]

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

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


ЗЫ А не идиотизм писать логи чата в БД?

[QUOTE=zorkk]2shaelf
...где 8000 запросов ежесекундно (ну кроме монстров вроде яндекса и гугла - там принципиально иные системы, в которых РНР места быть не может по определению).[/QUOTE]
Во первых : 8000 запросов - это не предел для баз данных. Они расчитаны на большие нагрузки и если качественный хостер, то вывести из строя БД не так уж и просто.
Во-вторых : принцип кэширования запросов - не новость. Все ответы БД для повторяющихся запросов берутся из кэша.

[QUOTE=calgon]Они расчитаны на большие нагрузки
[/QUOTE]
Кто они? Oracle? Да расчитан. MS SQL? IBM DB? Да расчитаны. MySQL? Сильно сомневаюсь.

[QUOTE=calgon]если качественный хостер, то вывести из строя БД не так уж и просто.[/QUOTE]
Валяй. Твой аккаунт тут же заблокируют. Хостеры следят за нагрузкой на сервера создаваемой клиентами. На некоторые хостинги даже phpNuke не поставить - тут же банят за превышение нагрузки... А ты говоришь 8к запросов в секунду....

[QUOTE=zorkk]Кто они? Oracle? Да расчитан. MS SQL? IBM DB? Да расчитаны. MySQL? Сильно сомневаюсь.
[/QUOTE]
:D во-первых оракл расчитан на проекты поле действие которых лежит не только на сервисах услуг интернета, но и на таких как sms-сервис. Например оператор Jeans для проверки счета общается с Ораклом.
Да и обслуживание таких БД обходится дороговато (это даже мягко сказано).
Для несуперпупер крутых проектов с головой хватает мускула. Он прост и гибок в освоении.
Если ты испытываешь личную неприязнь к мускулу, так хоть не настраивай остальных против него. А мож ты ващще не в состоянии с ним работать :D.

[QUOTE=zorkk]
Валяй. Твой аккаунт тут же заблокируют. Хостеры следят за нагрузкой на сервера создаваемой клиентами. На некоторые хостинги даже phpNuke не поставить - тут же банят за превышение нагрузки... А ты говоришь 8к запросов в секунду....[/QUOTE]
Гы. Если б было все как ты говоришь мы б щас могли зайти только на microsoft.com :D. Есть много способов решения уменьшения нагрузки на сервак. Конечно, если речь идет о DDos-атаке так тут и забанивание :) всех аккаунтов не поможет.

[QUOTE=calgon]:D во-первых оракл расчитан на проекты поле действие которых лежит не только на сервисах услуг интернета, но и на таких как sms-сервис. [/QUOTE]

А я разве упоминал веб в своем ответе? А разве бывают "БД для веб", "БД не для веб"? Вообще-то даже MySQL можно использовать в приложениях весьма далеких от веб.

[QUOTE=calgon]А мож ты ващще не в состоянии с ним работать :D.[/QUOTE]
Хочешь помериться письками кто круче?? Детский сад ей-богу

[QUOTE=calgon]
Гы. Если б было все как ты говоришь мы б щас могли зайти только на microsoft.com [/QUOTE]

Мое заявление основано на реальном опыте. Хостер был американский.

[QUOTE=zorkk]А я разве упоминал веб в своем ответе? А разве бывают "БД для веб", "БД не для веб"? Вообще-то даже MySQL можно использовать в приложениях весьма далеких от веб.
[/QUOTE]
:D Не ну ты ващще смешной!! Видишь ветка форума : "Web программирование". Без комментариев.
[QUOTE=zorkk]
Хочешь помериться письками кто круче?? Детский сад ей-богу
[/QUOTE]
Мда.... видно я задел самолюбие. Бывает. :D
[QUOTE=zorkk]
Мое заявление основано на реальном опыте. Хостер был американский.[/QUOTE]
Т.к. народ у них недобросовестный. Для них лучше забанить аккаунт, чем оптимизировать работу сервака. Знаю такое. У нас люди более добросовестно относятся к своей работе.

2zorkk Ты за свои слова не привык отвечать, а только орать. Уже минимум в 2 местах ты облажался и тут хочешь?:)

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