Тема: Что хранить при аутентификации в сессиях?!!

Ну вообще, пыхчу я, кряхчу я, над очередным своим велосипедом и возник у меня следующий вопрос: какую инфу о пользователе следует хранить в сессиях?!!

Допустим, у нас есть сущность user

PHP код:

CREATE TABLE IF NOT EXISTS `user` (
  `user_id` int(11) NOT NULL AUTO_INCREMENT,
  `user_name` varchar(100) NOT NULL,
  `user_email` varchar(50) NOT NULL,
  `user_password_hash` varchar(40) NOT NULL,
  `registration_date` int(11) NOT NULL,
  PRIMARY KEY (`user_id`),
  UNIQUE KEY `user_email` (`user_email`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8; 


Само собою, в сессиях непосредственный интерес представляет как минимум поле user_id, иначе то нам никак не определить пользователя.

! В принципе в данном случае уникальным так же является поле user_email, но его как первичный ключ мы не используем!

Вернемся к сути самого вопроса, с небольшой перефразировкой: что, кроме user_id стоит хранить в сессиях?!

Я сохраняю user_id и IP адрес, с которого произошла аутентификация.

У меня так же есть необходимость в хранении информации об правах доступа активного пользователя, ее я так же храню в сессиях или же лучше каждый раз ее запрашивать из БД? При запросе тратим в среднем 0.03 c, в принципе не так критично, но все же....

Очень хотелось бы услышать ваше мнение!

В идеале в сессиях надо хранить только информацию об аутентификации пользователя, то есть именно UserID и информацию для проверки сессии, в данном случае это IP адрес, можно добавить еще UserAgent для более строгой защиты.

Смысла хранить другую информацию в сессии смысла нет, более того это не безопасно. например если хранить информацию о правах, то пользователь может получить доступ к системе даже тогда когда у него уже нет прав на доступ.

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

Например можно создать класс User у которого будет статический метод GetUser(@userID) и уже в это методе непосредственно заниматься получением данных из базы данных и созданием сущности User по этим данным. В будущем если станет актуальным вопрос производительности, этот метод можно будет расширить например поддержкой кэширования, что позволит значительно сократить время получения информации о пользователе.

Сообщение от Admin

...можно добавить еще UserAgent для более строгой защиты.

Вот с этим согласен, такая фишечка имеется, просто не была упомянута!

Сообщение от Admin

хранить информацию о правах, то пользователь может получить доступ к системе даже тогда когда у него уже нет прав на доступ.

Вот на счет этого, не скажи. Сессии чистить надо! Просто, в случае, если, что то не так, мочим сессию, точнее часть, отвечающею за user и все! как тут пользователь получит права?!

Сообщение от Admin

....путем абстракции объекта пользователь и интерфейса получения информации о пользователе, что поможет потом без проблем применять разные стратегии оптимизации.

Например можно создать класс User у которого будет статический метод GetUser(@userID) и уже в это методе непосредственно заниматься получением данных из базы данных и созданием сущности User....

Ну примерно так и сделал!

Мое решение:

Есть класс, назовем его UserAuth, он у умеет:

1. Хранить информацию о авторизованом пользователе
2. Производить авторизацию(вход/выход)
3. Запоминать пользователя по IP и UserAgent
4. Предоставлять инфу о пользователе (метод статический!!!)

в принципе для скромных нужд без использования прав доступа он годится, но у него есть еще одна особенность, он охраняет данные о пользователе в статистических переменных, которые неизменны для всех объектов класса, что позволяет избежать множественной авторизации!

А вот наследник класса UserAuth, назовем его UserAccess уже может оперировать правами, и так же хранит их и выдает через статические переменные и функции.

Как тебе такое решение?

Я правильно понял, что авторизация подразумевает только одного активного, авторизованного пользователя?
Странное решение.

Сообщение от Admin

Я правильно понял, что авторизация подразумевает только одного активного, авторизованного пользователя?
Странное решение.

ну а как еще? одновременно может быть авторизован только один!

PHP код:

class UserAuth
{
     protected static $_user_id = null;

     public function logIn($login, $pass, $remember)
     {
     // Авторизуется по параметрам
     }
} 


в $_user_id хранится идентификатор авторизованного пользователя(пардонте, не активного), из любого объекта класса мы обращаемся к одному и тому же пользователю!

Или я чето не понимаю?!

Парни подкиньте мне учебничек по ПХП. хочу научится. Буду рад если с примерами и практикой. еще и по джаве тоже скиньте.