• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

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

  • Автор темы name.is.gray
  • Дата начала
Статус
Закрыто для дальнейших ответов.
N

name.is.gray

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

вопрос: зачем каждую сессию писать в бд?
ответ: чтобы получить такое:
phpBB : Critical Error

Error creating new session

DEBUG MODE

INSERT INTO phpbb_sessions (session_id, session_user_id, session_start, session_time, session_ip, session_page, session_logged_in, is_robot, session_admin) VALUES ('c39eef84de6ee40201d9c70af6dd3048', 3391, 1139237593, 1139237593, 'c3de4304', 0, 1, '0', 0)

еще вопрос: а в чем польза-то?
 
G

Gisma

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

Guest_ExtremeRuff_*

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

Guest_ExtremeRuff_*

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

Gisma

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

Guest_Serg_*

INSERT INTO phpbb_sessions (session_id, session_user_id, session_start, session_time, session_ip, session_page, session_logged_in, is_robot, session_admin) VALUES ('c39eef84de6ee40201d9c70af6dd3048', 3391, 1139237593, 1139237593, 'c3de4304', 0, 1, '0', 0)
за такое надо убивать на месте
зачем нужна сессия? сессия нужна для сохранения переменных между сеансами связи конкретного браузера и сервера!
жесткий набор полей, хранящихся в сессии это ламеризм. создавая объект сессии, приложение должно получать в результате объект с набором полей, определенных в предыдущих сессиях. например 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 файла). ну дальше, думаю сам догадаешся
и не забудь в любом случае чистить безжизненные сессии хотя бы раз в неделю (это актуально и для файла, и для субд)
 
G

Gisma

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

Guest

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

Gisma

изначально нужно делать практично)
 
G

Guest_Serg_*

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

Andrew Stephanoff

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

Gisma

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

Guest_Serg_*

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

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

Gisma

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

Guest_Serg_*

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

Gisma

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

Guest_Serg_*

лан - внатуре чо-т отошли от темы
вернемся к
INSERT INTO phpbb_sessions (session_id, session_user_id, session_start, session_time, session_ip, session_page, session_logged_in, is_robot, session_admin) VALUES ('c39eef84de6ee40201d9c70af6dd3048', 3391, 1139237593, 1139237593, 'c3de4304', 0, 1, '0', 0)
попробуем так:
нужно сделать так, что бы незареганный пользователь, пытаясь попасть на страницу, требующую авторизации, проходил промежуточную процедуру авторизации
например, если страница, куда он пытается попасть - профайл пользователя, то, набрав .../profile.html он должен попасть на страницу авторизации, и, в случае успеха, попасть с нее на .../profile.html
 
Статус
Закрыто для дальнейших ответов.
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!