Мое почтение всем!
Есть такая проблема: Как убить переменные текущей сессии и саму сессию, если работа скрипта прервана по каким-либо причинам? Допустим если пользователь закрыл браузер, то данные всей сессии моментально автоматом убивались!

Это сообщение отредактировал(а) -=Ustas=- - 21.8.2005, 11:20

Если пользователь закрыл браузер, то скрипт продолжает работать.
А вообще есть session_destroy и unset, который уничтожает индексы массива $_SESSION

Цитата(Mal @ 21.8.2005, 13:35)

А вообще есть session_destroy и unset, который уничтожает индексы массива $_SESSION

Mal Hack, я курсе что есть. Мне нужно унитожить сессию именно тогда, когда пользователь вышел некорректным способом, т.е. просто закрыл браузер. Или здесь уже по любому придется юзать JavaScript?!

В данном случае ты ничего не заюзаешь. Как ты через JS отловить момент, когда закрывается ее база, тобиь движок браузера?
Нельзя так сделать.

Добавлено @ 17:55
Можно, конечно повесить на OnClose или OnExit, но это не всегда сработает.

Цитата(Mal @ 21.8.2005, 17:54)

Можно, конечно повесить на OnClose или OnExit, но это не всегда сработает.

Я это и имел ввиду. Т.е. не всегда работает?!

Цитата

Т.е. не всегда работает?!

Нет, конечно.

Тестировал такие скрипты работало в Opera, Firefox, IE. при конечно включенном Javascript, это называется 'exit консоль'

Цитата(Anarki @ 21.8.2005, 21:30)

Тестировал такие скрипты работало в Opera, Firefox, IE. при конечно включенном Javascript, это называется 'exit консоль'

А вот отсюда поподробнее... Примерчик мона?

А не проще выставить время работы сессии на период работы браузера? Т.е. как только пользователь закрыл браузер, сессия теряется.

А каким же образом мне получить это время?

А разве сессия по умолчанию не убивается когда закрывается браузер?
По крайней мере я так работал с админкой.
Все отлично убивалось когда я закрываю браузер.

Цитата(fara @ 22.8.2005, 08:51)

А разве сессия по умолчанию не убивается когда закрывается браузер? По крайней мере я так работал с админкой. Все отлично убивалось когда я закрываю браузер.

Нет. Ты что имел доступ к файлам сессий и видел что их там нет? Откуда у тебя такая уверенность?!

-=Ustas=- делается всегда таймаут работы сессии, реализовывается программно.

Ну так это же на какой-то определенный промежуток времени только. Ладно, буду искать другие решения. Тогда у меня попутный вопрос, может и не в тему, но все же: У меня в сессии хранится имя админа, его логин, id и еще одна логическая переменная, которые после особой проверки и сравнения, если все в норме - дают доступ к админке. Ну так вот, если по каким либо причинам эта сессия останется не разрегистрированной, то можно же ее спереть и использовать в своих коварных целях?! Или же для того, чтобы ее стянуть, нужно сервак ложить? Вот, в принципе, за что я переживаю!

По САБЖУ. Сейчас как раз этим и занимаюсь. Отслеживать закрытие браузера - ИМХО не выход лучше убивать сессии через определенный промежуток времени, если сессия в это время не была задействована (как сделано в форуме IPB). Вобще все данные сессий удобно хранить в базе данных, а для этого регистрировать обработчики сессий с помощью функции session_set_save_handler(). Сборкой мусора должен заниматься обработчик, который идет сюда последним параметром (условно назовем gc), время жизни сессий можно регулировать параметром session.gc_maxlifetime, который подается в обработчик сборки мусора.

Разумеется, если ты задумал хранить сессии в базе данных, необходимо указывать время создания или активации каждой сессии.

Цитата

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

можно, если только кто - нибудь угадает 32 х символьный SID .

Цитата(Perchilla @ 22.8.2005, 21:18)

можно, если только кто - нибудь угадает 32 х символьный SID .

Т.е. если я правильно понимаю, то сессии лучше всего сохранять в своей базе, нежели на жестком диске своего хостера?!

-=Ustas=-, в любом случае можно узнать SID и проникнуть в защищенную подобным образом страницу.
Есть несколько мудренных способов избежания данной проблемы, хотя 100% защиты все равно не будет.

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

А вообще если хочешь обезопаситься, введи контроль по IP

Это получается как здесь Mal Hack описывает?!

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

Да сессию можно украсть и васпользоваться ею - и поэтому нежелательно передавать в сессии пароль лучше после регистр. генери ключь и его записывай и в сессию и в б.д. (и время тоже записывай) а потом все это дело проверяй и обновляй

ОК, будем пробовать.
Добавлено @ 11:50

Цитата(IZ @ 23.8.2005, 11:40)

Я бы вообще порекомендовал + проверку HTTP_USER_AGENT и еще пары параметров.

Под парой параметров ты что понимаешь?

-=Ustas=-, HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT_ENCODING. Так же можно приколоться с записью в куку последнего порта сервера к которому подключался пользователь... ну и т.п.

IZ@TOP а смысл каждый раз хэш генерить?
Генерим при авторизации хэш из браузера, IP и имени пользователя или ID. Уникальность гарантирована.

Mal Hack, а теперь представь что этот хеш прут когда юзер по сайту лазит, тут то и получается что если кул-хацкер не успел зайти раньше чем юзер обновил страницу (ну перешел куда), то его попросту не пустит, мол хешик то у Вас - битый Хотя незнаю конечно насколько это актуально, но моя система это использует.

А про IP, это если только хеш делать который реально сравнивает текущий ИП юзера. Об этом я уже писал, проще разрешать доступ по корректному IP... хотя что делать если взломщик в той же сети что и юзер и прокся у них не показывает их IP, только внешний

IZ@TOP хэш пишетс в БД, и каждый раз при действии пользователя составляется скриптом и проверяется тем что в БД.

Цитата(Mal @ 23.8.2005, 15:01)

IZ@TOP хэш пишетс в БД, и каждый раз при действии пользователя составляется скриптом и проверяется тем что в БД.

А я о чем только еще добавляю что можно так же вносить в него рандомные данные и мешать позиции параметров в нем задействованных и обнавлять каждый раз.

Хотя конечно тут можно сказать что если юзверей много, это не оптимально...