NFSko v2.0 Pre-Alpha
Группа: Соадмины
Страна проживания: 
Уважение: 221 (98%)
|
2Bullet GT
Да пожалуйста 
Аутентификация состоит из двух частей — идентификация (определение имени) и авторизация (проверка пароля). Авторизация может быть проведена: по кукам (по хранимому хэшированному паролю), по идентификатору сессии (в принципе, тоже используются куки), по явно присланному логину-паролю в массивах Get или Post. Кроме того, возможна модификация метода авторизации по сессии, путём смены идентиикатора сессии при каждом запросе. Этот метод можно выделить как «авторизация по одноразовому паролю», когда другие относятся к группе «авторизация по многоразовому паролю».
Методы, связанные с проверкой идентификатора сессии общаются с таблицей базы данных «кто онлайн», и не получают никаких пользовательских настроек или права доступа. Кроме того, сессию надо не только читать из БД, но и записывать изменения обратно. Методы, связанные с проверкой пользовательского пароля читаю таблицу пользователей, а это относительно трудный запрос, т.к. таблица большая, но зато сразу можно получить все пользовательские настройки и права доступа, однако, сессию надо прописывать всё равно.
Выходит, что для простого достоверного определения пользователя необходимо проделать достаточно много действий, в том числе 2-3 запроса к БД. Был поставлен вопрос — а для той информации, которую пользователь хочет получить, вообще имеет значение, кто он такой, или нет? Если ответ на вопрос будет «нет», то эти 2-3 запроса к БД были в пустую. Или другой вопрос — а необходима ли проверка прав доступа к информации, или нет?
В соответствии с этими вопросами я прописал 5-и уровневую схему авторизации:
0 — идентификация по сессии (авторизации нет, БД не читается и не пишется)
1 — авторизация по ID сессии (по многоразовому паролю; права доступа минимальны — не читаются из БД)
2 — авторизация по кукам (по многоразовому паролю; настройки прав доступа читаются из БД)
3 — авторизация по изменяющемуся идентификатору сессии (по одноразовому паролю) и кукам (настройки прав доступа читаются из БД);
4 — авторизация по явно присланному логину-паролю в массивах Get или Post.
Добавлено спустя 13 дней 13 часа 44 минуты 11 секунд:
Фух, последнее время был занят тем, что снова перекапывал ядро, а именно всё, что связано с пользователем. Не нравилось мне, как было сделано, да и работало кривовато. Итог работы: 2 класса ушло на слом, ещё 3 написано.
Что мне не нравится: если куки установлены на 10 секунд, а время пользователя спешит на 10 секунд относительно времени сервера (куки устанавливаются не НА какое-то время, а ДО какого-то времени), то сессии фактически не будет, потому что куки будут тут же удаляться.
Вторым косяком является то, что сразу после авторизации вас, как пользователя, нет в списке онлайн. Это связано с тем, что как авторизация, так и получение списков онлайн производятся модулями параллельно с отображением, а регистрация сессии производится после обработки модулей. Таким образом, при авторизации сначала производится получение списков, а затем запись того, что вы вошли. Аналогичным образом, вы можете подать команду на выход, а при следующем обновлении страницы будет показано, что вы всё ещё в сети.
Судя по всему, касательно внутренней структуры, пришло время писать тот самый обработчик главных команд, который я аккуратно пропустил
Добавлено спустя 11 дней 2 часа 36 минут 22 секунды:
UPD
Постепенно, как я уже писал в другой теме, сделал файловый архив, галерею и модуль баг-трекинга, в котором можно просматривать, регистрировать и изменять статус багов. По задумке, любой пользователь может зарегистрировать найденный им баг и я уже буду реагировать на эти сообщения.
Предполагаю использовать именно этот модуль при закрытом или открытом тестировании, когда придёт время. Надеюсь на вашу помощь в тестировании.
|
Навигация: Главная форума -=- Главные форумы -=- Наш сайт