[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Разлогинить юзера
tazododu
Всем привет!
Погуглил, но сам сделать не смог.
Помогите советом - как разлогинить юзера из под админки?
session_destroy(); не подходит, т.к. удаляет сессию пользователя с под которого выполнена функция huh.gif



Спустя 7 минут, 20 секунд (11.03.2011 - 11:54) Snus написал(а):
tazododu
Если есть доступ к temp файлам , то пиши имя сессии в мускул, а через админку удаляй tmp-файл выбранного юзверя.

Спустя 3 минуты, 2 секунды (11.03.2011 - 11:57) kirik написал(а):
Цитата (tazododu @ 11.03.2011 - 03:47)
session_destroy(); не подходит, т.к. удаляет сессию пользователя с под которого выполнена функция

Для смены id сессии есть специальна функция session_id()

Спустя 40 минут, 9 секунд (11.03.2011 - 12:37) tazododu написал(а):
спасибо за варианты.
сделал
	session_id('hutquklat77snrn6n7s85p7ko2');
session_destroy();
session_id('v0kdbjmo93820hu8nmdpgl6m07');

а вообще весь сыр-бор из-за того, что меняется одна переменная $_SESSION['firmid']. может есть способ ее подменить у пользователя?

Спустя 14 часов, 45 минут, 51 секунда (12.03.2011 - 03:23) Shumomer написал(а):
Цитата (tazododu @ 11.03.2011 - 09:37)
может есть способ ее подменить у пользователя?

Что значит "подменить"? Вопрос точнее сформулируй, а то может тебе просто $_SESSION['firmid']="блабла"; надо.

Спустя 8 минут, 38 секунд (12.03.2011 - 03:32) Trianon написал(а):
сессии - это не тот механизм, посредством которого пользователя можно считать аутентифицированным.
Накладывая на механизм поддержки сессий роль аутентификатора, получаешь в результате кучу проблем, из которых трудность "разлогинивания" - самая легкая, пожалуй.

Спустя 32 минуты, 8 секунд (12.03.2011 - 04:04) inpost написал(а):
Trianon
Почему это? А какая альтернатива? Ты имеешь ввиду для админки аутентификация, или для обычного пользователя на сайте?

tazododu
Ты не всю сессию удаляй, а лишь те записи, где говорятся, что это админ.
К примеру unset($_SESSION['status']); unset($_SESSION['access']) и т.д.

Спустя 1 час, 11 минут, 38 секунд (12.03.2011 - 05:16) Trianon написал(а):
>Trianon
>Почему это? А какая альтернатива?

В процессе аутентификации клиент предъявляет серверу аутентификационный токен (authentical credentials) - некоторый набор данных, по которому сервер принимает решение о том, что клиент именно тот, за кого себя выдает, и никто другой.
Когдя пользователь логин с паролем вводит в форму - понятно, что является таким токеном.
Но он же не постоянно его вводит?
Что является токеном при последующих обращениях?


>Ты имеешь ввиду для админки аутентификация, или для обычного пользователя на сайте?

Не вижу разницы. Ни вижу и не хочу видеть.


>tazododu
>Ты не всю сессию удаляй, а лишь те записи, где говорятся, что это админ.
>К примеру unset($_SESSION['status']); unset($_SESSION['access']) и т.д.

И что это даст?
В собственной ссессии администратора отстрелится аутентификация.
А ТС нужно отстрелить чужой сеанс!
О чем он уже и поплакал, кстати.

Спустя 2 часа, 41 минута, 24 секунды (12.03.2011 - 07:57) kirik написал(а):
Цитата (Trianon @ 11.03.2011 - 19:32)
сессии - это не тот механизм, посредством которого пользователя можно считать аутентифицированным.

какое-то странное заявление. Это единственный доверенный источник информации, который привязан к конкретной сессии. Если ты положишь туда ключ logged_in = true, то почему его нельзя использовать для проверки "авторизованности" данной сессии? Другой вопрос - покажите как можно безопасно авторизовывать пользователя без использования "сессии"?

Цитата (tazododu @ 11.03.2011 - 04:37)
а вообще весь сыр-бор из-за того, что меняется одна переменная $_SESSION['firmid']. может есть способ ее подменить у пользователя?

Просто сделай в табличке пользователей (или как там у тебя..) еще одно поле "firmid", и меняй его. Зачем его в сессию складывать, если это значение привязывается к пользователю, а не к сессии.

Спустя 1 час, 25 минут, 50 секунд (12.03.2011 - 09:23) Trianon написал(а):
Цитата (kirik)
Это единственный доверенный источник информации, который привязан к конкретной сессии.


Это - это что?
Что является источником?
И что значит "доверенный источник"?

И если он таки единственный (и при этом ущербный) - наверное стоит подумать, а не запастись ли другими источниками?

Цитата (kirik)
Если ты положишь туда ключ logged_in = true, то почему его нельзя использовать для проверки "авторизованности" данной сессии?


Для проверки авторизации - можно.
Для прорверки аутентичности - увы.

Спустя 1 час, 2 минуты, 56 секунд (12.03.2011 - 10:26) kirik написал(а):
Цитата (Trianon @ 12.03.2011 - 01:23)
Это - это что?
Что является источником?

Коровье молоко является источником кальция и насыщенных жиров.

Цитата (Trianon @ 12.03.2011 - 01:23)
И если он таки единственный (и при этом ущербный) - наверное стоит подумать, а не запастись ли другими источниками?

Всё в ваших руках. Только наврядли вы сможете придумать свой мега-гениальный механизм отличный от сессионного.

Цитата (Trianon @ 12.03.2011 - 01:23)
Для проверки авторизации - можно.
Для прорверки аутентичности - увы.

Да ну?? Вам в гугл надо идти работать с такой информацией.. или ещё куда.

Спустя 1 час, 4 минуты, 38 секунд (12.03.2011 - 11:30) Trianon написал(а):
kirik, если Вам по делу сказать нечего, то я, пожалуй, завершу дискуссию.

Спустя 14 минут, 2 секунды (12.03.2011 - 11:44) Michael написал(а):
Я тоже не совсем понимаю про что Trianon говорит. Может какое то недопонимание в терминах?
Цитата
Когдя пользователь логин с паролем вводит в форму - понятно, что является таким токеном.
Но он же не постоянно его вводит?
Что является токеном при последующих обращениях?

id сессии(в куке или там еще где), по которому система аутентифицирует пользователя(все данные у системы для этого есть, если пользователь до этого аутентифицировался логином и паролем)
Цитата
Для проверки авторизации - можно.
Для прорверки аутентичности - увы.

Гугл, мне подсказывает, что идет сначала аутентификация, а потом авторизация.

Спустя 15 минут, 52 секунды (12.03.2011 - 12:00) Trianon написал(а):
Окей. Под словом "авторизация" и вправду понимают разное. Я готов подвинуться в терминах.

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

Спустя 33 минуты, 55 секунд (12.03.2011 - 12:34) Michael написал(а):
Trianon, под идентификацией вы понимаете - когда пользователь пытается сообщить о себе системе(или своим логином/паролем или присвоенным ему id-шником)?
Цитата (Trianon)
Для проверки аутентичности его явно недостаточно.

А что будет достаточно? Можно, на конкретном примере?



Спустя 1 час, 2 минуты, 22 секунды (12.03.2011 - 13:37) tazododu написал(а):
ох ничего себе обсуждение в какую сторону пошло!
авторизация на сайте-то у меня имеется, причем нормаль сделанная. просто имеется ряд значений, которые я храню в сессии у юзера(вытащил при первичной авторизации и все).

проблема возникла тогда, когда мне понадобилось одну из переменных ему переопределять во время его активного сеанса.

вот я и подумал а нельзя ли администратору залогиненому в админке с сессией Х поменять переменную в сессии залогиненного на сайте пользователя Y....

Спустя 48 минут, 15 секунд (12.03.2011 - 14:25) killer8080 написал(а):
Для того чтоб это сделать нужно:
1. знать id сессии Y
2. иметь доступ на запись к директории где хранятся сессии

Спустя 4 минуты, 35 секунд (12.03.2011 - 14:29) Trianon написал(а):
Цитата (Michael)

Trianon, под идентификацией вы понимаете - когда пользователь пытается сообщить о себе системе(или своим логином/паролем  или присвоенным ему id-шником)?


Ну паролем, положим, этого не сообщишь (почему?) , а логином или SID - да, именно это.
Цитата (Michael)



Цитата (Trianon)
Для проверки аутентичности его явно недостаточно.

А что будет достаточно? Можно, на конкретном примере?


Нет, на конкретном примере нельзя - это будет слишком просто.
Давайте рассуждать.

на мой взгляд, достаточно будет сообщить нечто, что может сообщить, с точки зрения сервера, только данный (идентифицировавший себя) клиент.

SID под этот критерий попадает весьма со скрипом. Имеется куча мест где он хранится в открытом виде. А если вспомнить опцию session.use_trans_sid - то не только хранится, но и навязывается третьим лицам в некоторых случаях.

Спустя 7 минут, 10 секунд (12.03.2011 - 14:37) Trianon написал(а):
Цитата
вот я и подумал а нельзя ли администратору залогиненому в админке с сессией Х поменять переменную в сессии залогиненного на сайте пользователя Y....


В принципе, до нее можно дотянуться. И killer8080 подсказал, при каких условиях.
Вот только будет это слегка через заднее крыльцо.

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

Спустя 1 час, 17 минут, 55 секунд (12.03.2011 - 15:54) Michael написал(а):
Цитата
Ну паролем, положим, этого не сообщишь (почему?)

я говорил о паре - логин плюс пароль, может записал неудачно ... smile.gif
Цитата
Имеется куча мест где он хранится в открытом виде.

открытом виде для кого? Злоумышленника? Где и как?

Спустя 4 часа, 22 минуты, 28 секунд (12.03.2011 - 20:17) sergeiss написал(а):
Цитата (tazododu @ 12.03.2011 - 14:37)
авторизация на сайте-то у меня имеется, причем нормаль сделанная. просто имеется ряд значений, которые я храню в сессии у юзера(вытащил при первичной авторизации и все).

проблема возникла тогда, когда мне понадобилось одну из переменных ему переопределять во время его активного сеанса.

А самое-то главное и не сказал - как она у тебя сделана, авторизация-то smile.gif

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

Спустя 3 минуты, 58 секунд (12.03.2011 - 20:21) neadekvat написал(а):
Цитата (sergeiss @ 12.03.2011 - 17:17)
например, где-то в БД храним эту инфу, в т.ч. и то, что передать), то передаём ему это "что-то". Или меняем. Короче говоря, делаем то, что хотим сделать.

Боюсь, если бы автор мог понять то, что вы сейчас написали, он бы не задавал вопросов.

Для начала, я думаю, автору нужно ответить на вопрос, который уже не раз задавали. Где хранится информация о залогиненых пользователях. Только обычные сессии, или делаются записи с id сессии в базе данных, например.

Спустя 49 минут, 48 секунд (12.03.2011 - 21:11) Trianon написал(а):
Цитата
я говорил о паре - логин плюс пароль, может записал неудачно ...  smile.gif

Так а пароль лишний для той цели. Ибо логин - идентификатор уникальный.

Цитата
открытом виде для кого? Злоумышленника? Где и как?

В открытом - суть - не зашифрованном. просто байт за байтом.
Может про кучу я и превеличил. Но вот одно всяко - каталог временных сессионных файлов.
Частенько доступный отнюдь не только скриптам данного виртуального хоста.




Спустя 21 минута, 27 секунд (12.03.2011 - 21:32) kirik написал(а):
Цитата (Trianon @ 12.03.2011 - 13:11)
В открытом - суть - не зашифрованном. просто байт за байтом.
Может про кучу я и превеличил. Но вот одно всяко - каталог временных сессионных файлов.
Частенько доступный отнюдь не только скриптам данного виртуального хоста.

Это не проблема сессионного механизма, это проблема конкретного программиста, который не позаботился о безопасности своего проекта.

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

Спустя 11 часов, 49 минут, 22 секунды (13.03.2011 - 09:22) Trianon написал(а):
Цитата
Это не проблема сессионного механизма, это проблема конкретного программиста, который не позаботился о безопасности своего проекта.


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


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


Я не знаю такого механизма, как "висит кука, а на сервере запись, привязанная к" .
С моей точки зрения это демагогия.
Одна и та же кука может быть установлена на разных браузерах, в разных профилях пользователей и и на разных машинах.
К какой из кук привязана хранящаяся запись?
Чем таким она привязана?
Демагогия.

Механизм: Клиент показал - сервер проверил, принял решение, сделал вывод.
Через сессии оно там, или через какие другие реализации.

Спустя 1 день, 28 минут, 51 секунда (14.03.2011 - 09:50) tazododu написал(а):
Цитата
Для начала, я думаю, автору нужно ответить на вопрос, который уже не раз задавали. Где хранится информация о залогиненых пользователях. Только обычные сессии, или делаются записи с id сессии в базе данных, например.


инфа хранится в таблице юзеров, храню только сессион айди.
так все же, много слов и куча рассуждений, а вопрос-то простой, можно ли все-таки в, например, $_SESSION['key'] чужой сессии засунуть свое значение??
зная сессон айди пользователя.

Спустя 2 часа, 52 минуты, 40 секунд (14.03.2011 - 12:43) Trianon написал(а):
Цитата
а вопрос-то простой, можно ли все-таки в, например, $_SESSION['key'] чужой сессии засунуть свое значение??


Блин горелый.
Это не простой. Это сложный вопрос.

В частности, если Вы самой постановкой этого вопроса утверждаете, что чужая сессия на данный момент поднята (session_start() выполнен, а session_commit() еще нет) , то записывать что либо в файл сохранения сессии во-первых не позволит механизм блокировок, а во-вторых, даже если бы и позволил - записанные данные будут перекрыты реальными данными поднятой сесси в момент её явного или неявного session_commit()

Если отмахнуться от Вашего же упоминания $_SESSION в постановке вопроса, и предположить, что такая попытка выполняется между запросами чужой сессии - таки да, может быть и выйдет. Правда свою сессию на это время придется прикрыть.

На вопрос как это сделать, отвечать не буду, ибо ответ вреден для.
Очень надеюсь, что тот, кто знает, тоже промолчит.

Спустя 2 часа, 27 минут, 29 секунд (14.03.2011 - 15:11) Guest написал(а):
Trianon
ох, уважаемый, ну и запутали Вы меня ...

Спустя 49 секунд (14.03.2011 - 15:11) tazododu написал(а):
Trianon
ох, уважаемый, ну и запутали Вы меня ...

Спустя 4 часа, 30 минут, 26 секунд (14.03.2011 - 19:42) killer8080 написал(а):
Trianon
Ну вообще то интервал между session_start() и session_commit() равен времени выполнения скрипта (от нескольких миллисекунд, до нескольких секунд, зависит от ресурсоёмкости скрипта и быстродействия и загрузки сервера)
Цитата
Правда свою сессию на это время придется прикрыть.

Зачем? Почему нельзя так?
$user_ses_id= "0075c37cd760d38ea992ef3f7813b069"; // id сессии юзера, каким то способом полученый
$user_ses_file= ini_get("session.save_path")."/sess_".$user_ses_id; // файл сессии юзера

if(file_exists($user_ses_file)){
$i= 0;
// если файл занят, ждём пока освбодится
while(!is_writable($user_ses_file) && $i < 100){
$i++; // защита от зависания
usleep(10000);
}
if(is_writable($user_ses_file)){
$current_session= $_SESSION; // кешируем свою сессию
session_decode(file_get_contents($user_ses_file)); // декодируем сессию юзера
$_SESSION['var_name']= "new_value"; // вносим изменения
file_put_contents($user_ses_file, session_encode()); // записываем обратно в файл
$_SESSION= $current_session; // восстонавливаем данные своей сессии
unset($current_session);
}
else{
echo "session file not writable";
}
}

else{
echo "session file not found";
}

Спустя 2 часа, 35 минут, 28 секунд (14.03.2011 - 22:17) tazododu написал(а):
killer8080
хороший способ!

Спустя 16 часов, 12 минут, 43 секунды (15.03.2011 - 14:30) Michael написал(а):
Trianon, возвращаясь к вопросу о сессиях и аутентификации.
Предлагаете - ставить дополнительную куку (хранящуюся в БД в зависимости от id_юзера и его сессии)?
В друпале ip так дополнит. запоминают только(вроде) и я так делал раньше.

Спустя 24 минуты, 20 секунд (15.03.2011 - 14:54) Trianon написал(а):
так вроде sergeiss уже сказал.
Попробую развить.

Ведется таблица сессий.
При входе пользователя (открытии сессии) генерируется случайная строка, которая устанавливается кукой в браузер в качестве credentials, и записывается в строку таблицы вместе с другими параметрами:
- credentials,
- user_id,
- session_id() (если хотите связать штатные php-сессии с контролируемыми Вами),
- IP (если считаете, что в пределах сессии ip меняться не должен),
- время начала
- время последней активности etc...

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

Спустя 36 минут, 8 секунд (15.03.2011 - 15:30) Michael написал(а):
я думал как то необычно может будет, все таки с начала темы более загадочно все звучало rolleyes.gif

Спустя 21 час, 6 минут, 38 секунд (16.03.2011 - 12:37) kirik написал(а):
Цитата (Trianon @ 14.03.2011 - 04:43)
На вопрос как это сделать, отвечать не буду, ибо ответ вреден для.
Очень надеюсь, что тот, кто знает, тоже промолчит.

=)


Цитата (Trianon @ 15.03.2011 - 06:54)
Ведется таблица сессий.
При входе пользователя (открытии сессии) генерируется случайная строка, которая устанавливается кукой в браузер в качестве credentials, и записывается в строку таблицы вместе с другими параметрами:

Круто! И что мы получаем отличного от обычного сессионного механизма? И главное смысл всего этого?

Спустя 4 часа, 48 минут, 37 секунд (16.03.2011 - 17:26) killer8080 написал(а):
Да вешать вторую уникальную куку смысла вообще нет.

Спустя 6 часов, 57 минут, 56 секунд (17.03.2011 - 00:24) kirik написал(а):
Цитата (killer8080 @ 14.03.2011 - 11:42)
Зачем? Почему нельзя так?

А зачем? На уровне ядра php в функциях записи/чтения уже продуманы такие "ожидания". Пока один скрипт заблокировал файл, второй будет ждать разблокировки файла. Посему это лишнее.

Спустя 9 часов, 23 минуты, 32 секунды (17.03.2011 - 09:47) killer8080 написал(а):
А если файл заблокирован на время большее чем max execution time?

Спустя 2 часа, 23 минуты, 45 секунд (17.03.2011 - 12:11) kirik написал(а):
Цитата (killer8080 @ 17.03.2011 - 01:47)
А если файл заблокирован на время большее чем max execution time?

Это же всегда можно узнать :)

Скрипт №1
$fp = fopen('/tmp/lock.txt', 'w+');

if (flock($fp, LOCK_EX)) { // do an exclusive lock
fwrite($fp, 'Script 1');
sleep(ini_get('max_execution_time') + 10);
flock($fp, LOCK_UN); // release the lock
} else {
echo 'Couldn\'t get the lock!';
}

fclose($fp);


Скрипт №2
$fp = fopen('/tmp/lock.txt', 'w+');

if (flock($fp, LOCK_EX)) { // do an exclusive lock
fwrite($fp, 'Script 2');
flock($fp, LOCK_UN); // release the lock
} else {
echo 'Couldn\'t get the lock!';
}

fclose($fp);


Сначала запускаешь первый, потом сразу второй.

Ответ: будет ждать пока файл откроется => time_limit на дисковые операции не распространяется (в мануале об этом сказано)

Спустя 2 часа, 35 минут, 30 секунд (17.03.2011 - 14:46) Michael написал(а):
Цитата (killer8080 @ 16.03.2011 - 16:26)
Да вешать вторую уникальную куку смысла вообще нет.

Аргументы?

Спустя 48 минут, 50 секунд (17.03.2011 - 15:35) killer8080 написал(а):
kirik
Частично согласен с замечанием, is_writable возвращает true независимо от того, открыт файл другим процессом, или нет. Но и ваш пример не безгрешен. Оба скрипта выкинут Fatal Error max execution time
Цитата
time_limit на дисковые операции не распространяется (в мануале об этом сказано)

Хотелось бы увидеть ссылочку

Цитата
Аргументы?

В уникальности session_id никто не сомневается, что даёт второй уникальный Id?

Спустя 14 минут, 50 секунд (17.03.2011 - 15:50) Michael написал(а):
Цитата (killer8080 @ 17.03.2011 - 14:35)
Цитата
Аргументы?

В уникальности session_id никто не сомневается, что даёт второй уникальный Id?

Чуть выше в этой теме обсуждалось. Я подумал, может ты не согласен, имеешь свои аргументы против, а ты мне вопросы задаешь ...

Спустя 19 минут, 32 секунды (17.03.2011 - 16:10) killer8080 написал(а):
Странно blink.gif я вроде не делал высказываний против.
Оба метода имеют право на жизнь, у каждого свои плюсы и минусы.
Привязка БД исключает одновременное использование аккаунта разными людьми, а стандартные сессии снижают нагрузку на сервер, исключая лишние запросы к БД.

Спустя 50 минут, 20 секунд (17.03.2011 - 17:00) Michael написал(а):
Цитата (killer8080 @ 17.03.2011 - 15:10)
Странно blink.gif

действительно smile.gif .
Выше обсуждалось зачем обязательно ставить дополнительную куку.
А потом ты пишешь:
Цитата (killer8080)
Да вешать вторую уникальную куку смысла вообще нет.


Противоречие, как бы не? wink.gif laugh.gif

Спустя 9 минут, 27 секунд (17.03.2011 - 17:09) killer8080 написал(а):
Цитата (Trianon @ 15.03.2011 - 13:54)
Ведется таблица сессий.
При входе пользователя (открытии сессии) генерируется случайная строка, которая устанавливается кукой в браузер в качестве credentials, и записывается в строку таблицы вместе с другими параметрами:
- credentials,
- user_id,
- session_id() (если хотите связать штатные php-сессии с контролируемыми Вами),
- IP (если считаете, что в пределах сессии ip меняться не должен),
- время начала
- время последней активности etc...

Я имел ввиду, если в таблицу пишется session_id(), то второй id создавать ни к чему.
В чём противоречие?

Спустя 4 часа, 5 минут, 56 секунд (17.03.2011 - 21:15) kirik написал(а):
Цитата (killer8080 @ 17.03.2011 - 07:35)
Оба скрипта выкинут Fatal Error max execution time

С какого это?

UPD. агааа.. под виндами - да, на нормальных системах время sleep не учитывается как время выполнения скрипта (пруф).

Цитата (killer8080 @ 17.03.2011 - 07:35)
Хотелось бы увидеть ссылочку
Цитата (killer8080 @ 17.03.2011 - 08:10)
стандартные сессии снижают нагрузку на сервер, исключая лишние запросы к БД.

Стандартные сессии повышают нагрузку на диск, что гораздо хуже.

Цитата (killer8080 @ 17.03.2011 - 08:10)
Привязка БД исключает одновременное использование аккаунта разными людьми

Если это всё что хотел донести товарищ Trianon, то это не защитит от использования одного аккаунта с двух браузеров, больше внесет путаницы в систему. С таким же успехом такого результата можно добиться просто переведя сессии на БД и добавить поле user_id.. без всяких посторонних кук.
Цитата (killer8080 @ 17.03.2011 - 09:09)
если в таблицу пишется session_id(), то второй id создавать ни к чему.

да, вот.. smile.gif

Спустя 14 часов, 45 минут, 35 секунд (18.03.2011 - 12:01) killer8080 написал(а):
kirik
Насчёт слипа понятно, но речь шла о том что файл занят другим процессом. Где написано, что время файловых операций не учитывается, как время работы скрипта?
Как показал эксперимент - это справедливо только под линуксом (скорее всего под всеми юниксами), под виндой всё как обычно через ж...
Но если учесть, что подавляющее большинство хостингов под *никсами, то согласен этим можно пренебречь.

Цитата (kirik @ 17.03.2011 - 20:15)
Если это всё что хотел донести товарищ Trianon, то это не защитит от использования одного аккаунта с двух браузеров, больше внесет путаницы в систему. С таким же успехом такого результата можно добиться просто переведя сессии на БД и добавить поле user_id.. без всяких посторонних кук.

Я не знаю кто и что хочет донести, я всего лишь высказываю свою точку зрения. Привязка к БД не защитит от кражи куки, а если юзер просто заходил с чужого компа, и оставил открытую сессию, то да. После входа с другого браузера, старая сессия автоматически окажется разлогинена, в таблице ведь хранится id с последнего захода.

Спустя 14 часов, 59 минут, 21 секунда (19.03.2011 - 03:00) kirik написал(а):
Цитата (killer8080 @ 18.03.2011 - 04:01)
Где написано, что время файловых операций не учитывается, как время работы скрипта?

На странице set_time_limit:
Цитата (http://php.net/manual/en/function.set-time-limit.php)
Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc.


Цитата (killer8080 @ 18.03.2011 - 04:01)
Я не знаю кто и что хочет донести, я всего лишь высказываю свою точку зрения.

Я и не дискутировал с тобой smile.gif Интересно было бы услышать что-нибудь внятное от Trianonа.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.