запись сессий в бд

Тема в разделе "PHP программирование", создана пользователем name.is.gray, 6 фев 2006.

Статус темы:
Закрыта.
  1. name.is.gray

    name.is.gray Гость

    уважаемые девелоперы, любящие работать с сессиями!

    вопрос: зачем каждую сессию писать в бд?
    ответ: чтобы получить такое:
    еще вопрос: а в чем польза-то?
     
  2. Gisma

    Gisma Гость

    в том что сессия дохнет почти наверняка если ты закроешь браузер и подождешь минут 5
     
  3. Guest_ExtremeRuff_*

    Guest_ExtremeRuff_* Гость

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

    Gisma Гость

    а это уже от браузера зависит:)
     
  5. Guest_ExtremeRuff_*

    Guest_ExtremeRuff_* Гость

    Сессия имеет право жить! Gisma, а как с тобой связаться то???
     
  6. Gisma

    Gisma Гость

    мылом и ирц
    посмотри мои контакты! позвони на 2519063 (город), либо 2271151 (МТС) и выйди на связь!!!!:ph34r:
     
  7. Guest_Serg_*

    Guest_Serg_* Гость

    за такое надо убивать на месте
    зачем нужна сессия? сессия нужна для сохранения переменных между сеансами связи конкретного браузера и сервера!
    жесткий набор полей, хранящихся в сессии это ламеризм. создавая объект сессии, приложение должно получать в результате объект с набором полей, определенных в предыдущих сессиях. например perl:
    use Session;
    $session = Session::new();
    все. после этого метод new спер из кукисов сид и поднял из файла/базы сохраненные поля или сделал редирект на страницу логина(или завел новую), если сессия определена как неверная или ворованная. например, для восстановленной или новой сессии уже должно быть определено как минимум:
    $session->{'sid'}
    $session->{'UserAgent'}
    $session->{'IP'}
    + какие-то дополнительные поля. например, сделанные за сессию покупки (интернет-магазин), путь пользователя в ресурсе (статистика). модуль и репозиторий сессий не должен косячицца при изменении политики использования сессий в различных ресурсов. иначе (результат плохой проектировки) резко возрастает себестоимость программинга, что влечет затягивание сроков сдачи и завышение цен.
    если данные храняца в базе (что более громоздко), то делается 2 таблицы: первая для хранения данных, по которым определяется принадлежность сессии. Например:
    $session->{'id'} - айдишник сессии в таблице сессий
    $session->{'sid'}
    $session->{'UserAgent'} - лучше мд5(или другой хэш) от него, что бы обойтись varchar-ом
    $session->{'IP'}
    $session->{'UserID'}
    $session->{'ext'} - есть ли дополнительные данные
    все. больше там ничего быть не должно. эта таблица содержит индексы по всем полям, кроме ЮзерИД и экст.
    вторая таблица - таблица дополнительных данных. содержит свой примари-кей, айдишник сессии (берем из первой таблицы. он же индекс. если юзаеш не мускуль, то желательно завязать его через триггер на онделит из первой). и 2 колонки - название-значение дополнительного параметра.
    сразу предупреждаю, что сессии, реализованные через субд на серванте с большой нагрузкой желательно отвалить на отдельную субд или, хотя бы на отдельную базу (да-да. придеца сделать отдельный хендлер на нее) а вообще, юзай файлы и не парься. герениш сид (например, 32 символа из [A-Z][a-z][0-9]) и храниш это в отдельной папке (а лучше в дереве вида: корень_репозитория/первая_буква_сида/вторая_буква_сида/)
    имя файла - сид (он же храница в кукисах юзера)
    в файле через разделитель (например, ### или \n или придумай сам) записи. записи вида: имя_поля===значение поля (здесь === разделитель. не нравица этот - придумай другой) в конструкторе тыриш сид из кукисов и поднимаеш файл сессии (если он есть). проверяеш корректность сессии (например, юзерагент обязательно - кукис не может перекочевать корректно из осла в мазилку. mtime файла). ну дальше, думаю сам догадаешся
    и не забудь в любом случае чистить безжизненные сессии хотя бы раз в неделю (это актуально и для файла, и для субд)
     
  8. Gisma

    Gisma Гость

    Guest_Serg_* :)
    ну и что ты хотел рассказать нам? Обосновать необходимость работы с сессиями через класс?;) Мол проектирование не страдает;) это круто, но что-то я плохо представляю изменения механизма работы сессий на сервере (а следовательно необходимость в нем я не вижу)
     
  9. Guest

    Guest Гость

    хотел показать, что делать изначально надо универсально
    иначе в последствии придеца переделывать под конкретный проджект
     
  10. Gisma

    Gisma Гость

    изначально нужно делать практично)
     
  11. Guest_Serg_*

    Guest_Serg_* Гость

    практично -- ето как?
    вот делаю я ща один проект
    когда основное техзадание было сделано, пошли такие навороты, что если бы сессии были жесткие, то пришлось бы их переписывать
    а тут просто вкатил нужные данные, потом выкинул когда не нужно и вуаля - все наман
    и ваще объекты рулят немерянно.
    особенно када за конторой тянецца шлейф постоянно поддерживаемых продуктов, то без собственной универсальной платформы никак.
    смысл в том, что бы под заказчика затачивать интерфейс. а айпи должен обеспечиваца стандартными модулями. иначе хана... :D - поддержа задавит весь девелопинг
    я знаю одну контору, которая ща агонизирует из-за этого... набрали дофига проектов, свои программеры едва успевают поддерживать то что уже есть, а с новыми программерами совсем напряг (в москве за 1.5 килобакса хрен найдеш людей -- одни студенты или энтузиасты, которым даже показать-то нечего... - у меня оттуда знакомый свалил недавно). а платить больше они не могут - иначе летом этот чел будет убыточным (летом сильно падает колличество и стоимости заказов - все кормяцца в основном поддержкой того, что сделали)
     
  12. Andrew Stephanoff

    Andrew Stephanoff Гость

    Если есть необходимость работы с сессиями через класс, то лучше сделать абстрактный класс Session с минимально необходимым набором полей и наследовать уже от него.
     
  13. Gisma

    Gisma Гость

    не представляю никаких наворотов для которых потребуется сессия:D
    Опять же не следует ставить разделение в документ->представление в альфу и омегу:D
    Я повторяю нужна практичность в первую очередь
     
  14. Guest_Serg_*

    Guest_Serg_* Гость

    to Andrew Stephanoff
    это уже детали реализации
    смысл - в универсальном хранилище

    любой сервис, предусматривающий выбор чего-либо пользователем с последующей обработкой выбранных вещей - например, электромагазин(или любая электропродавалка), электрогазета/журнал, электрообменник... в общем дофига всего
    вот сделал ты электромагазин, а на след день приходит заказчик и говорит вот народ - надо сделать любому посетителю сравнивалку отобранных им товаров, выводить мемберу меню самых посещаемых им разделов,.. в общем, сделать что-то, что требует привязки данных, передаваемых между скриптами, к браузеру
    и кстати, чо имееца введу под практичностью?
    а нащот объекта-сессии... ну, если угодно, можно сделать ее и просто модулем.. и везде писать global $session, передавая хэш из скрипта в скрипт...
     
  15. Gisma

    Gisma Гость

    зачем этот крейсер сессии??:D:D
    а насчет сессий в таком применении (магазины) то это глупость в куки ID корзины, а на базе данных сама корзина. Вот это я имею ввиду под практичностью
     
  16. Guest_Serg_*

    Guest_Serg_* Гость

    :D
    корзину надо к сессии привязывать
    юзеру - сид (sid = session id), серверу - репозиторий, однозначно открывающийся по сиду
    детали реализации - на усмотрение девелопера. если это корзина электромагазина, то нет смысла сувать ее в отдельное место - я не помню, что бы кто-то заказывал сотни товаров. если корзина - данные привязанные к аккаунту (но не к сессии -- например, ордера или счета мембера - или любые мемберские данные), то да - имеет смысл выносить их в отдельный репозиторий.
    смысл в том, что потом, когда припрет делать статистику и аналитику, желательно иметь это все в одном месте. к тому же практичность в разносе хранилищ данных привязанных к сессии меня как раз с практической точки зрения смущает...
    чем больше хранилищ, тем сложнее обслуживание и возрастает шанс, что при переносе на другую тачку (к другому клиенту) кто-то что-то забудет...
    вообще пытаюсь бороться с громоздкой архитектурой как могу.
    а если данные сессии по-определению должны храница где-то в отдельном месте, то делаеца потомок сессии, который будет обрабатывать их так, как нужно. программинга - минимум, пользы - максимум
    сессию я имею ввиду не данные мембера, а данные просто посетителя (он даже не регался - просто зашел на сайт)
     
  17. Gisma

    Gisma Гость

    Опять зачем же потомок сессий?:) зачем эта архитектурная монструозность:D
    напиши плиз интерефейс этого класса;)
    Более просто создать парочку процедур автоматизирующих операции с данными о клиенте на КОНКРЕТНОМ сайте, чем писать класс, интрегрировать, а потом се равно дописывать методы этого класса.
    Нужно путать ООП с потворном использованием кода (хотя именно близость этих понятий и создает путаницу)
     
  18. Guest_Serg_*

    Guest_Serg_* Гость

    лан - внатуре чо-т отошли от темы
    вернемся к
    попробуем так:
    нужно сделать так, что бы незареганный пользователь, пытаясь попасть на страницу, требующую авторизации, проходил промежуточную процедуру авторизации
    например, если страница, куда он пытается попасть - профайл пользователя, то, набрав .../profile.html он должен попасть на страницу авторизации, и, в случае успеха, попасть с нее на .../profile.html
     
Загрузка...
Статус темы:
Закрыта.

Поделиться этой страницей