Ваш сайт становится все более популярным, еженедельно бьются рекорды посещаемости.
Вы включаете кеширование, разбираетесь в нюансах настроек и оптимизируете.
Но наступает момент, когда одного сервера уже недостаточно, и переход на самую крутую железку в мире не находит полного понимания у властей.
Ах да, вы храните ID пользователя в PHP Session в файле и вроде бы морально готовы занести всё в базу данных, как рекомендует Интернет. Но что-то вас останавливает.
Сомнения!
Сомнения в целесообразности использования базы данных для хранения Сессий.Сессии, в которых всего пара элементов — идентификатор пользователя и его роль.
Или даже просто идентификатор администратора.
Вас преследуют сетевые издержки, новые сущности и теорема CAP. Каждую ночь вас преследует один и тот же кошмар — не забывайте букву Б в слове Memcached… Всё, давайте посмотрим на альтернативу — хранение идентификатора клиента на своей стороне, в Cookies.
Итак, постановка задачи.
Так что
- Масштабируемый
- Безопасно
- Быстрый
- Только
«Порядок и беспорядок — это вопрос количества».
Решение
В Cookies выбираем две переменные — одна будет хранить открытый ключ, другая — данные.Пишем бессмысленную строку текста в коде программы; это будет наш секретный ключ.
Во время инициализации мы генерируем вектор инициализации — наш открытый ключ.
Мы записываем и читаем данные посредством симметричного шифрования, используя оба этих ключа.
Не будем забывать о сериализации.
Это позволит вам хранить данные разных типов.
Выгода.
Вы только что стали на шаг ближе к архитектуре без общего доступа.
Преимущества и недостатки
С масштабированием здесь все в порядке — оно ограничено только фильтрацией Кука на стороне клиента.Передача пары по запросу решает эту проблему.
Таким образом, любой случайный сервер из вашего пула сможет корректно обработать запрос, а балансировщик трафика может замедлиться до уровня сети той же модели.
Проблема периодической замены секретного ключа решается наличием в программе двух ключей.
Давайте попробуем их по порядку.
Теперь давайте улучшим защиту.
Давайте установим время жизни Кука равным 0. Тогда закрытие браузера приведет к повторной генерации открытого ключа в следующий раз.
Для усложнения расшифровки будем использовать «длинный» алгоритм с ключом в 256 бит. Далее мы привяжем открытый ключ к IP-адресу клиента.
Например, потому что мд5 И MCRYPT_RIJNDAEL_256 прекрасно дополняют друг друга:
Чтобы предотвратить создание базы для криптоанализа, мы используем команду сна для каждой неудачной попытки входа в систему.$secret = md5(md5('My secret key') .md5($_SERVER['REMOTE_ADDR']));
Охранники могут заменить его штампом и заблокировать IP вместе с аккаунтом.
Отправить вертолёт. Симметричное шифрование быстрее, чем сетевая связь.
Вы еретик, если выдергиваете базу данных, хоть локальную, хоть в оперативной памяти, хоть при постоянном соединении или через сокет, при каждом нажатии, когда вам этого делать не надо.
«Привет, %ID%» мы можем показать сразу, без накладных расходов.
Работать с Cookies в приложении сложнее, чем с сеансом.
Особенно, если последняя используется как мини-база данных и отображается на экране в разных местах программы.
Мы знаем, что это плохая практика; темное прошлое усложнит вам путь к светлому будущему.
Так пусть же популярность вашего сервиса станет мотиватором для рефакторинга! В конце концов, вы нужны вашим клиентам, а они нужны вам.
С фреймворками MVC определенно проще.
Нужно больше кода!
Класс для Zend Framework 1.x, реализующий хранилище файлов cookie аутентификации — здесь .Даже если вы не используете ZF при высоких нагрузках (хм, автор почему-то в этом уверен), то среднестатистическому джедаю достаточно пары сотен строк кода, чтобы понять и воспроизвести принцип в своем любимом рамки или session_set_save_handler .
Вторник.
Автор будет благодарен за любые найденные где-либо ошибки.
Теги: #php #Cookies #аутентификация #php #Zend Framework
-
«Я Начал Много Думать О Мелочах»
19 Oct, 24 -
С Днем Рождения, Эдсгер Вибе Дейкстра.
19 Oct, 24 -
Трудно Быть Юниором
19 Oct, 24 -
Добро Пожаловать В Новый Интерфейс Поиска!
19 Oct, 24
