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

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

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

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

Кстати. У меня интернет такой, что при каждом подключении к провайдеру IP-адрес присваивается рандомный. Это к вопросу о том, почему на данном сайте авторизация слетает. На своих то сайтах я давно предпочитаю отключать привязку к IP-адресу.]]> Tue, 23 Jun 2009 11:55:24 -0000 Trustmaster
Хмм, а на других движках работает вроде как? Странно...]]> Tue, 23 Jun 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 домен для куков. Хотя всегда ранее задавал данный параметр. Теперь все нормально. Куки записываются. Авторизация слетать больше не должна.]]> Mon, 22 Jun 2009 18:52:06 -0000 Kort Mon, 22 Jun 2009 18:06:54 -0000 Boss
Блин посмотрел щас. Куки вообще не создаются, за счет сессии только держимся. Посмотрим...]]> Mon, 22 Jun 2009 14:21:09 -0000 Trustmaster Mon, 22 Jun 2009 13:34:28 -0000 Boss Mon, 22 Jun 2009 11:52:03 -0000 Dr2005alex Mon, 25 May 2009 15:55:23 -0000 Boss Mon, 25 May 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;
 }
]]> Fri, 24 Apr 2009 21:21:13 -0000 Trustmaster Fri, 24 Apr 2009 20:12:33 -0000 Ratibor стоят два сайта на одном хостинге,
отличия только в скинах, на одном стандартный, на другом свой.
файлы движка обсолютно идентичны.
Там где стандартный скин, то можно войти на страницу авторизации,
а там где свой, то нельзя.
Пробовал закинуть users.auth.tpl от стандартного, все равно не заходит.
Самое интересное если к примеру сперва попробовать зайти на те странички, которые доступны авторизованным пользователям, к примеру pm.php, то сперва ругается что вам не позволено это делать, а потом преспокойненько перебрасывает на страницу авторизации.
У кого какие мысли ?
Почему просто по ссылке users.php?m=auth не заходит ?]]> Thu, 23 Apr 2009 22:38:48 -0000 Boss До этого тестировал все нормально было. Вроде по части авторизации ничего не правил. Ну да ладно. У меня причина была в отправляемой форме.

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

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

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

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

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

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

Тем, кто сейчас использует Cotonti 0.0.3, можно в качестве временного решения до выхода новой версии советовать ставить в админке Maximum cookie lifetime в значение 1800 (хотя может и побольше будет работать, надо проверять). А после установки следующей версии им придётся опять сходить в админку и поменять это значение.]]> Sun, 15 Mar 2009 03:16:16 -0000 Trustmaster Sun, 15 Mar 2009 02:58:50 -0000 dervan
В секундах есть свои преимущества - можно как и раньше ставить интервалы меньше, чем сутки. И что lang-файлы при откате назад на секунды не придётся переделывать - тоже большой плюс.]]> Sun, 15 Mar 2009 02:54:13 -0000 Trustmaster Sun, 15 Mar 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.[/][/]]]> Sat, 14 Mar 2009 20:41:57 -0000 esclkm 2. версия?
3. на скольких компах используется 1 аккаунт?]]> Sat, 14 Mar 2009 19:03:38 -0000 Boss Sat, 14 Mar 2009 17:58:44 -0000 jcrush Fri, 13 Mar 2009 16:23:10 -0000 Boss
ps: В настройках $cfg['ipcheck'] = FALSE; значит эта причина сразу отпадает.]]> Fri, 13 Mar 2009 15:42:20 -0000