Подход для аутентификации и хранения пользовательских данных

Question

Я использую Zend Framework, но мой вопрос в целом касается сессий / баз данных / аутентификации (PHP MySQL).

В настоящее время это мой подход к аутентификации:

1) Пользователь входит в системуПодробности проверяются в базе данных.- Действительно стандартные вещи.

2) Если данные верны, в сеансе хранится только уникальный идентификатор пользователя и токен безопасности (уникальный идентификатор пользователя + IP + информация браузера + соль).Сессия записана в файловую систему.

• Я читал вокруг, и многие говорят, что хранение вещей в сессиях не очень хорошая идея, и что вы должны действительно написать только уникальный идентификатор, который ссылается навернуться к деталям пользователя и токен безопасности для предотвращения перехвата сеанса.Так что это подход, который я выбрал, я использую, чтобы записать детали пользователя в сессии, но я переместил это.Хотелось узнать ваше мнение по этому поводу.
• Я держу сессии в файловой системе, так как я не работаю на нескольких серверах, и так как я записываю лишь крошечные данные в сессии, я подумалэта производительность была бы выше, если держать сеансы в файловой системе, чтобы уменьшить нагрузку на базу данных.После того, как сессия написана для аутентификации, с этого момента она становится доступной только для чтения.

3) Остальные данные пользователя (такие как подписка, разрешения, информация об учетной записи и т. Д.) Кэшируются вфайловая система (ее всегда можно легко перенести в память, если я хочу еще большей производительности).

• Таким образом, вместо сохранения данных пользователя в сеансе, данные пользователя кэшируются в файловой системе.Я использую Zend_Cache, а уникальный идентификатор кэша - это что-то вроде md5 (/ cache / auth / 2892), число - это уникальный идентификатор пользователя.Я предполагаю, что преимущество этого метода состоит в том, что, как только пользователь вошел в систему, по существу, не выполняются запросы к базе данных для получения сведений о пользователе.Просто подумайте, лучше ли этот подход, чем хранить весь лот в сеансе ...

4) Когда пользователь перемещается по сайту, проверяется только идентификатор в сеансе и безопасностьтокен.

Итак, в целом первый вопрос: 1) является ли файловая система более эффективной, чем база данных, для этой цели 2) принял ли я достаточные меры безопасности 3) отделяет детали пользователя от сеанса в кэшированный файл ибессмысленная задача?

Спасибо.

Answer 1

Вы спрашиваете о разных вещах.

Сессия

Сессии в PHP быстрые и эффективные. Тысячи небольших дисковых сессий на умеренно обновленном сервере не станут узким местом для производительности. Ни один из них не пишет свои собственные обработчики (очень легко; в руководстве по PHP есть примеры), чтобы поместить его в базу данных.

О правилах сессий, которые рекомендуются наилучшим образом: только дать веб-браузеру одну вещь - идентификатор сессии. Размещение только зарегистрированного идентификатора пользователя в сеансе и извлечение этих данных из БД, когда они вам нужны, также является наилучшей практикой. Это также означает, что пользовательская информация может быть изменена, и они получат ее при обновлении следующей страницы.

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

Возможно, вы также захотите внедрить свой собственный тайм-аут входа в систему с помощью переменной сеанса. Параметры сборки мусора в php.ini предназначены для управления хранением данных сеанса, а не для тайм-аутов входа в систему.

Кэширование

Это сложная тема, и вам, вероятно, нужно начать собирать показатели (обычно время загрузки страницы), прежде чем что-либо реализовывать.

Для реализации любого вида кэширования вам необходимо учитывать время жизни данных, которые вы кэшируете, и то, насколько дорогостоящей будет их повторная генерация при потере кэша. Просто бросить memcache на проблему - это , а не решение; вам все еще нужно понимать параметры кэширования и то, как memcache их интерпретирует. Это также относится к любому решению для постоянного хранения, в том числе к дисковым сеансам, но я выделяю memcache, потому что он высококлассный и имеет довольно агрессивный механизм истечения срока действия.

Часто пропускаемый пример загружает одни и те же данные из базы данных несколько раз на странице: хороший ORM сделает это за вас, не полагаясь на кэширование запросов MySQL. Еще один пример, о котором забывают, это небольшие запросы, которые выполняются на каждой странице: кэшируйте их всего на несколько секунд на умеренно загруженном сервере, и загрузка базы данных значительно упадет.

Наконец, кэширование на нескольких уровнях часто намного эффективнее и масштабируемо, чем один раз, потому что они могут использовать истечения времени друг друга. Он также хорошо абстрагируется: например, спрятать его в ORM, и он теоретически доступен незаметно и автоматически для всех ваших объектов.

Answer 2

1) Вы можете легко проверить, что быстрее, сделав скрипт цикла. В любом случае, недостатком использования файловой системы является необходимость обновления кэшированного файла каждый раз, когда вы обновляете базу данных. Копии данных - это вообще плохо. Кроме того, если у вас нет миллионов посетителей, я не думаю, что будет какая-либо практическая разница в скорости в любой из стратагий. И ... чтобы не забыть, сессии также хранятся в файловой системе. Один файл для каждой сессии.

Является ли запрос быстрее, чем файловая система: зависит. Включено ли кэширование запросов. В MySql это по умолчанию, и вам может повезти, и вам нужен только доступ к памяти. Если нет, то БД в любом случае должен выполнить проверку файловой системы. Во-вторых, насколько оптимизирован ваш запрос с индексами. Насколько жесткий диск сервера.

3) Зависит от скорости извлечения его из БД. В общем, кеширование может повлиять на производительность, но кэширование в памяти было бы еще лучше при использовании memcached или чего-то подобного. Вообще я бы избегал копий данных в файлах. Но, конечно, если для запроса данных из БД потребуются секунды, перейдите к кешированию файловой системы. Кроме того, если у вас много пользователей ... например, 10.000+, вам нужно создать какую-нибудь систему папок, поскольку размещение 10.000 кэшированных файлов в одной папке замедляет время доступа ...