Погуглил, но сам сделать не смог.
Помогите советом - как разлогинить юзера из под админки?
session_destroy(); не подходит, т.к. удаляет сессию пользователя с под которого выполнена функция
Спустя 7 минут, 20 секунд (11.03.2011 - 11:54) Snus написал(а):
tazododu
Если есть доступ к temp файлам , то пиши имя сессии в мускул, а через админку удаляй tmp-файл выбранного юзверя.
Если есть доступ к 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['firmid']. может есть способ ее подменить у пользователя?
сделал
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']) и т.д.
Почему это? А какая альтернатива? Ты имеешь ввиду для админки аутентификация, или для обычного пользователя на сайте?
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']) и т.д.
И что это даст?
В собственной ссессии администратора отстрелится аутентификация.
А ТС нужно отстрелить чужой сеанс!
О чем он уже и поплакал, кстати.
>Почему это? А какая альтернатива?
В процессе аутентификации клиент предъявляет серверу аутентификационный токен (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....
авторизация на сайте-то у меня имеется, причем нормаль сделанная. просто имеется ряд значений, которые я храню в сессии у юзера(вытащил при первичной авторизации и все).
проблема возникла тогда, когда мне понадобилось одну из переменных ему переопределять во время его активного сеанса.
вот я и подумал а нельзя ли администратору залогиненому в админке с сессией Х поменять переменную в сессии залогиненного на сайте пользователя Y....
Спустя 48 минут, 15 секунд (12.03.2011 - 14:25) killer8080 написал(а):
Для того чтоб это сделать нужно:
1. знать id сессии Y
2. иметь доступ на запись к директории где хранятся сессии
1. знать id сессии Y
2. иметь доступ на запись к директории где хранятся сессии
Спустя 4 минуты, 35 секунд (12.03.2011 - 14:29) Trianon написал(а):
Цитата (Michael) |
Trianon, под идентификацией вы понимаете - когда пользователь пытается сообщить о себе системе(или своим логином/паролем или присвоенным ему id-шником)? |
Ну паролем, положим, этого не сообщишь (почему?) , а логином или SID - да, именно это.
Цитата (Michael) | ||
А что будет достаточно? Можно, на конкретном примере? |
Нет, на конкретном примере нельзя - это будет слишком просто.
Давайте рассуждать.
на мой взгляд, достаточно будет сообщить нечто, что может сообщить, с точки зрения сервера, только данный (идентифицировавший себя) клиент.
SID под этот критерий попадает весьма со скрипом. Имеется куча мест где он хранится в открытом виде. А если вспомнить опцию session.use_trans_sid - то не только хранится, но и навязывается третьим лицам в некоторых случаях.
Спустя 7 минут, 10 секунд (12.03.2011 - 14:37) Trianon написал(а):
Цитата |
вот я и подумал а нельзя ли администратору залогиненому в админке с сессией Х поменять переменную в сессии залогиненного на сайте пользователя Y.... |
В принципе, до нее можно дотянуться. И killer8080 подсказал, при каких условиях.
Вот только будет это слегка через заднее крыльцо.
Цель сессионного механизма - сохранять состояние некоторого контекста переменных сеанса определенного клиента.
Администратор же при попытке поменять значение такой переменной банальным образом хочет эту цель нарушить.
Опять же что сразу приходит в голову: Если на некоторую переменную в силу тех или иных обстоятельств приходится воздействовать из разных сеансов, то она не является локальной по отношению к сеансу пользовательскому, а является общей.
Общие переменные такого рода обычно хранят в БД, в таблице активных сессий, в строке, соответствующей данному сеансу.
И к ней процесс администратора в силу расставленных в модели ролей будет иметь доступ вполне чистый, законный и естественный.
Спустя 1 час, 17 минут, 55 секунд (12.03.2011 - 15:54) Michael написал(а):
Цитата |
Ну паролем, положим, этого не сообщишь (почему?) |
я говорил о паре - логин плюс пароль, может записал неудачно ...
Цитата |
Имеется куча мест где он хранится в открытом виде. |
открытом виде для кого? Злоумышленника? Где и как?
Спустя 4 часа, 22 минуты, 28 секунд (12.03.2011 - 20:17) sergeiss написал(а):
Цитата (tazododu @ 12.03.2011 - 14:37) |
авторизация на сайте-то у меня имеется, причем нормаль сделанная. просто имеется ряд значений, которые я храню в сессии у юзера(вытащил при первичной авторизации и все). проблема возникла тогда, когда мне понадобилось одну из переменных ему переопределять во время его активного сеанса. |
А самое-то главное и не сказал - как она у тебя сделана, авторизация-то
И почему-то все дружно говорили про сессию, но слово "куки" почему-то не прозвучало ни разу!!!
ОК. В случае успешной аутентификации делаем запись в куки на компе юзера. Далее, при каждом обращении к серверу смотрим, что же у него в куки имеется... И если это нужный нам юзер (например, где-то в БД храним эту инфу, в т.ч. и то, что передать), то передаём ему это "что-то". Или меняем. Короче говоря, делаем то, что хотим сделать.
Спустя 3 минуты, 58 секунд (12.03.2011 - 20:21) neadekvat написал(а):
Цитата (sergeiss @ 12.03.2011 - 17:17) |
например, где-то в БД храним эту инфу, в т.ч. и то, что передать), то передаём ему это "что-то". Или меняем. Короче говоря, делаем то, что хотим сделать. |
Боюсь, если бы автор мог понять то, что вы сейчас написали, он бы не задавал вопросов.
Для начала, я думаю, автору нужно ответить на вопрос, который уже не раз задавали. Где хранится информация о залогиненых пользователях. Только обычные сессии, или делаются записи с id сессии в базе данных, например.
Спустя 49 минут, 48 секунд (12.03.2011 - 21:11) Trianon написал(а):
Цитата |
я говорил о паре - логин плюс пароль, может записал неудачно ... |
Так а пароль лишний для той цели. Ибо логин - идентификатор уникальный.
Цитата |
открытом виде для кого? Злоумышленника? Где и как? |
В открытом - суть - не зашифрованном. просто байт за байтом.
Может про кучу я и превеличил. Но вот одно всяко - каталог временных сессионных файлов.
Частенько доступный отнюдь не только скриптам данного виртуального хоста.
Спустя 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() равен времени выполнения скрипта (от нескольких миллисекунд, до нескольких секунд, зависит от ресурсоёмкости скрипта и быстродействия и загрузки сервера)
Ну вообще то интервал между 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 так дополнит. запоминают только(вроде) и я так делал раньше.
Предлагаете - ставить дополнительную куку (хранящуюся в БД в зависимости от id_юзера и его сессии)?
В друпале ip так дополнит. запоминают только(вроде) и я так делал раньше.
Спустя 24 минуты, 20 секунд (15.03.2011 - 14:54) Trianon написал(а):
так вроде sergeiss уже сказал.
Попробую развить.
Ведется таблица сессий.
При входе пользователя (открытии сессии) генерируется случайная строка, которая устанавливается кукой в браузер в качестве credentials, и записывается в строку таблицы вместе с другими параметрами:
- credentials,
- user_id,
- session_id() (если хотите связать штатные php-сессии с контролируемыми Вами),
- IP (если считаете, что в пределах сессии ip меняться не должен),
- время начала
- время последней активности etc...
К процессу генерации строки credentials следует отнестись ответственно.
Нужно исключить возможность генерации наперед заданного значения такой строки вследствие проявления побочных эффектов генератора псевдослучайных чисел, либо доступа к параметрам, определяющим его поведение.
Атаки на таком принципе реализовывались, и задевали, скажем так, воображение, своей дерзостью.
Попробую развить.
Ведется таблица сессий.
При входе пользователя (открытии сессии) генерируется случайная строка, которая устанавливается кукой в браузер в качестве credentials, и записывается в строку таблицы вместе с другими параметрами:
- credentials,
- user_id,
- session_id() (если хотите связать штатные php-сессии с контролируемыми Вами),
- IP (если считаете, что в пределах сессии ip меняться не должен),
- время начала
- время последней активности etc...
К процессу генерации строки credentials следует отнестись ответственно.
Нужно исключить возможность генерации наперед заданного значения такой строки вследствие проявления побочных эффектов генератора псевдослучайных чисел, либо доступа к параметрам, определяющим его поведение.
Атаки на таком принципе реализовывались, и задевали, скажем так, воображение, своей дерзостью.
Спустя 36 минут, 8 секунд (15.03.2011 - 15:30) Michael написал(а):
я думал как то необычно может будет, все таки с начала темы более загадочно все звучало
Спустя 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
Частично согласен с замечанием, 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 написал(а):
Странно я вроде не делал высказываний против.
Оба метода имеют право на жизнь, у каждого свои плюсы и минусы.
Привязка БД исключает одновременное использование аккаунта разными людьми, а стандартные сессии снижают нагрузку на сервер, исключая лишние запросы к БД.
Оба метода имеют право на жизнь, у каждого свои плюсы и минусы.
Привязка БД исключает одновременное использование аккаунта разными людьми, а стандартные сессии снижают нагрузку на сервер, исключая лишние запросы к БД.
Спустя 50 минут, 20 секунд (17.03.2011 - 17:00) Michael написал(а):
Цитата (killer8080 @ 17.03.2011 - 15:10) |
Странно |
действительно .
Выше обсуждалось зачем обязательно ставить дополнительную куку.
А потом ты пишешь:
Цитата (killer8080) |
Да вешать вторую уникальную куку смысла вообще нет. |
Противоречие, как бы не?
Спустя 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 создавать ни к чему. |
да, вот..
Спустя 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) |
Я не знаю кто и что хочет донести, я всего лишь высказываю свою точку зрения. |
Я и не дискутировал с тобой Интересно было бы услышать что-нибудь внятное от Trianonа.