cotonti.com : Слет авторизации https://www.cotonti.com Останні повідомлення в темі Cotonti en Tue, 07 Apr 2026 19:53:22 -0000 Boss
Одна интересная мысль... Авторизация зачем чаще всего нужна? Чаще чтобы писать в форуме и оставлять комментарии. Так почему бы поля ввода логина и пароля не выводить прямо в форме отправки сообщений. Авторизован или нет - пофигу. Ввел свой логин и пароль и отправил сообщение/комментарий. Учитывая, что данные поля у большинства заполняются браузером, напряга меньше, чем если авторизоваться предварительно перед отправкой через отдельную форму. Но форуме ixbt так сделано. http://forum.ixbt.com/topic.cgi?id=13:36206-26

>Будут :-) Оливье переводит Сед на UTF-8.
Так SED еще будет развиваться?]]> Ср, 24 Чер 2009 00:13:21 -0000 Trustmaster Оливье переводит Сед на UTF-8.

Авторизация сразу в нескольких браузерах отрублена преднамеренно - от XSS и CSRF подальше. То же и про привязку к IP. Блажь параноидальная, конечно. Но это до первого серьёзного взлома. Так что думайте сами, что дороже.]]> Вт, 23 Чер 2009 21:18:59 -0000 Sergey Вт, 23 Чер 2009 14:35:28 -0000 Boss Если я просто PHP-файл создавал с одной строчкой внутри. Проблема похоже именно в браузере.

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

Кстати. У меня интернет такой, что при каждом подключении к провайдеру IP-адрес присваивается рандомный. Это к вопросу о том, почему на данном сайте авторизация слетает. На своих то сайтах я давно предпочитаю отключать привязку к IP-адресу.]]> Вт, 23 Чер 2009 11:55:24 -0000 Trustmaster
Хмм, а на других движках работает вроде как? Странно...]]> Вт, 23 Чер 2009 03:55:41 -0000 Boss
Такой код НЕ работает с любым доменом:

<?PHP
setcookie("TEST", "12345", (time()+60*60*24*7), "/", "site.ru");
?>

А такой без проблем создает куки:

<?PHP
setcookie("TEST", "12345", (time()+60*60*24*7), "/");
?>

Т.е. функция не работает если задать домен для кука. ХЗ кто виноват. Использую последнюю версию мозилы, может дело в ней. В итоге убрал в настройках COT домен для куков. Хотя всегда ранее задавал данный параметр. Теперь все нормально. Куки записываются. Авторизация слетать больше не должна.]]> Пн, 22 Чер 2009 18:52:06 -0000 Kort Пн, 22 Чер 2009 18:06:54 -0000 Boss
Блин посмотрел щас. Куки вообще не создаются, за счет сессии только держимся. Посмотрим...]]> Пн, 22 Чер 2009 14:21:09 -0000 Trustmaster Пн, 22 Чер 2009 13:34:28 -0000 Boss Пн, 22 Чер 2009 11:52:03 -0000 Dr2005alex Пн, 25 Травень 2009 15:55:23 -0000 Boss Пн, 25 Травень 2009 14:12:27 -0000 Ratibor А в лисе сразу пишет что сценарий или типа того не может быть завершен,
в общем какой то цикл который не может быть завершен.

В общем временно решил проблемму закоментировав в users.auth.inc.php:
if (empty($redirect))
 {
	sed_redirect(sed_url('users', 'm=auth&redirect='. base64_encode($sys['referer']), '', true));
	exit;
 }
]]> Пт, 24 Кві 2009 21:21:13 -0000 Trustmaster Пт, 24 Кві 2009 20:12:33 -0000 Ratibor стоят два сайта на одном хостинге,
отличия только в скинах, на одном стандартный, на другом свой.
файлы движка обсолютно идентичны.
Там где стандартный скин, то можно войти на страницу авторизации,
а там где свой, то нельзя.
Пробовал закинуть users.auth.tpl от стандартного, все равно не заходит.
Самое интересное если к примеру сперва попробовать зайти на те странички, которые доступны авторизованным пользователям, к примеру pm.php, то сперва ругается что вам не позволено это делать, а потом преспокойненько перебрасывает на страницу авторизации.
У кого какие мысли ?
Почему просто по ссылке users.php?m=auth не заходит ?]]> Thu, 23 Кві 2009 22:38:48 -0000 Boss До этого тестировал все нормально было. Вроде по части авторизации ничего не правил. Ну да ладно. У меня причина была в отправляемой форме.

Вот этот фикс снимите, он ложный.
http://trac.cotonti.com/ticket/248

Без него все нормально.]]> Ср, 18 Бер 2009 13:20:46 -0000 Trustmaster Boss, у тебя динамический IP, который постоянно меняется. Поэтому неудивительно, что слетает авторизация на этом сайте. Вот если ipcheck=FALSE, то это уже другое дело. Но чтобы выяснить, в чём оно состоит, надо очень чётко фиксировать последовательность действий, которая приводит к слёту авторизации. Потому что если проблема с сабмитом форм - это одно, а если просто при сёрфинге - это совсем другое. И частота вылетов тоже очень важна.]]> Ср, 18 Бер 2009 12:31:52 -0000 dervan
Поставил Cotonti 0.0.3 с нуля, ошибка начала стабильно повторяться. Сделал исправления, как рассказано выше, больше эта ошибка не появляется.

Boss, пожалуйста посмотри у себя подробнее, что происходит - сейчас из твоего сообщения неясно, что и где искать.

И ещё: если ты сделал патч r636, не забудь в админке вернуть Maximum cookie lifetime в значение 5184000. И на всякий случай почисти cookie в браузере.

P.S.
Если ты заходишь по HTTPS, то cookie авторизации слетают после сеанса - так и должно быть, это специально сделано.]]> Ср, 18 Бер 2009 09:51:26 -0000 Boss Вт, 17 Бер 2009 23:43:39 -0000 dervan
Только исправлять код надо иначе - выложенный здесь вариант сделан из неверного предположения, что была изменена единица измерения.

Правильный вариант исправления кода здесь: r636.]]> Вт, 17 Бер 2009 06:13:04 -0000 Boss
зыЖ Админы, вы бы еще на этом сайте подкрутили настройки.]]> Пн, 16 Бер 2009 22:33:48 -0000 dervan $expire.

Тем, кто сейчас использует Cotonti 0.0.3, можно в качестве временного решения до выхода новой версии советовать ставить в админке Maximum cookie lifetime в значение 1800 (хотя может и побольше будет работать, надо проверять). А после установки следующей версии им придётся опять сходить в админку и поменять это значение.]]> Нд, 15 Бер 2009 03:16:16 -0000 Trustmaster Нд, 15 Бер 2009 02:58:50 -0000 dervan
В секундах есть свои преимущества - можно как и раньше ставить интервалы меньше, чем сутки. И что lang-файлы при откате назад на секунды не придётся переделывать - тоже большой плюс.]]> Нд, 15 Бер 2009 02:54:13 -0000 Trustmaster Нд, 15 Бер 2009 02:25:24 -0000 dervan $expire при вызове функцищи sed_setcookie(). Параметр имеет тип int, а вычисляется сейчас так:
time()+$cfg['cookielifetime']*86400
При этом значение $cfg['cookielifetime'] по умолчанию '5184000', т.е. происходит превышение максимально возможной величины для int, и в результате получается cookie с Expires = Session.

Исправление ошибки.

Найти в system/functions.admin.php строку:
	$result[] = array ('main', '10', 'cookielifetime', 2, '5184000', array (1800,3600,7200,14400,28800,43200,86400,172800, 259200,604800,1296000,2592000,5184000));
и поправить:
	$result[] = array ('main', '10', 'cookielifetime', 2, '60', array(1,2,3,7,15,30,60));

Найти в system/lang/en/admin.lang.php строку:
$L['cfg_cookielifetime'] = array('Maximum cookie lifetime', 'In seconds');
и поправить:
$L['cfg_cookielifetime'] = array('Maximum cookie lifetime', 'In days');
Аналогичные исправления сделать в других языковых файлах.

Зайти в Administration panel / Configuration / Main setup и там поправить Maximum cookie lifetime :, например на 60.[/][/]]]> Сб, 14 Бер 2009 20:41:57 -0000 esclkm 2. версия?
3. на скольких компах используется 1 аккаунт?]]> Сб, 14 Бер 2009 19:03:38 -0000 Boss Сб, 14 Бер 2009 17:58:44 -0000 jcrush Пт, 13 Бер 2009 16:23:10 -0000 Boss
ps: В настройках $cfg['ipcheck'] = FALSE; значит эта причина сразу отпадает.]]> Пт, 13 Бер 2009 15:42:20 -0000