BiTel

Форум BiTel
bgbilling.ru     docs.bitel.ru     wiki.bitel.ru     dbinfo.bitel.ru     bgcrm.ru     billing.bitel.ru     bitel.ru    
Текущее время: 24 июн 2025, 17:35

Часовой пояс: UTC + 5 часов [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 16 ] 
Автор Сообщение
СообщениеДобавлено: 29 окт 2014, 23:07 
Не в сети

Зарегистрирован: 29 янв 2014, 11:32
Сообщения: 365
Карма: 10
После второй неудачной попытки ввода пароля в кабинете пользователя выдает страницу:
Код:
ОШИБКА: Доступ заблокирован

Доступ к статистике по договору 1 заблокирован, до разблокировки осталось - 0:57:00

Возможные причины:

    Для защиты от подбора пароля к серверу статистики методом перебора, после каждой попытоки войти на сервер статистики с неправильным паролем, доступ к серверу блокируется на некоторое время. После истечения этого времени дается возможность провести еще одну попытку войти на сервер, если будет вновь введен неправильный пароль доступ снова будет заблокирован на более длительный промежуток времени и т.д. После нескольких последовательных попыток входа на сервер с неправильным паролем, доступ на сервер блокируется на несколько часов.
    Доступ заблокирован администратором, свяжитесь с службой поддержки по тел. +X (XXX) XXX-XX-XX
    Другие причины, для выяснения свяжитесь с расчетной службой по тел. +X (XXX) XXX-XX-XX

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

Обратите внимание на:

    Состояние клавиши Caps Lock и языковую раскладку клавиатуры
    Пароль для доступа к серверу статистики ОТЛИЧАЕТСЯ от пароля для доступа по VPN. Пароль для доступа к серверу статистики указывается в карте регистрации выдаваемой при заключении договора.
    Если не уверены в корректности вводимого пароля, попробуйте воспользоваться системой восстановления пароля


Хотя в конфигурации задано:
Код:
#----------------------------------------
# Web-интерфейс, доступ, защита от подбора пароля
#----------------------------------------
# максимальное количество неудачных попыток авторизации подряд
logon.counter.max=20
# базовый интервал времени в секундах между неудачными попытками авторизации
logon.timeout.period=0
# время блокировки в секундах после исчерпания количества попыток авторизации
logon.timeout.lock=21600
# размер кэша паролей
logon.lock.cache.size=100
# время устаревания записи в кэше паролей в секундах
logon.lock.cache.expired=600
# алгоритм увеличения времени между попытками (+ или ^)
logon.timeout.action=+


Во-первых: непонятно почему послу второй попытки такая страница выскакивает
Во-вторых откуда такое время ожидания - 1 час?

Проблема появилась, похоже, после последнего обновления, хотя гарантий не даю.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 29 окт 2014, 23:29 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4494
Откуда: Уфа, Россия
Карма: 187
конфиг когда прописали? давно?
сервер пробовали ребутнуть?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 29 окт 2014, 23:59 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4494
Откуда: Уфа, Россия
Карма: 187
попробуйте обновиться


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 30 окт 2014, 12:16 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6055
Карма: 244
таймзоны обновите, 90% что в них часть вашего дела, уже сталкивались с таким
и версии всегда показывайте из about, без них рассматривать обращение с ошибкой лишено смысла

_________________
I'm clever. I've got a computer.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 30 окт 2014, 12:48 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
кстати, тоже столкнулись с подобным давеча. Не придал значения, думал проблема клиента.
Но таймзоны на системе и в java у нас обновлены были заранее. А вот в Mysql - не сразу заметили и обновили только во вторник. Может быть с этим связано.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 ноя 2014, 08:21 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Снова столкнулись.
Разобрался - в contract_logon_last заносятся неправильные данные:

Код:

mysql> SELECT * FROM contract_logon_last where dt>now();
+---------------------+--------+---------------------+---+---------------+
| lu                  | cid    | dt                  | n | ip            |
+---------------------+--------+---------------------+---+---------------+
| 2014-11-06 09:28:31 | 212541 | 2014-11-06 10:33:49 | 0 | x.x.x.x |
+---------------------+--------+---------------------+---+---------------+
1 row in set (0.01 sec)

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2014-11-06 10:17:33 |
+---------------------+
1 row in set (0.00 sec)



Посмотрел по коду - dt заполняется только через now()
Хотя вот же - у меня now() выдаёт нормальное время!

Мы чинили таймзоны mysql только во вторник, 28.10.2014, а BGBillingServer с тех пор не перезагружали.
Т.е. скорее всего для mysql-коннектов, которые были созданы до починки таймзон mysql, now() выдаёт время по-старому.
Сегодня буду перезагружать все приложения биллинга.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 ноя 2014, 12:16 
Не в сети
Аватара пользователя

Зарегистрирован: 30 май 2008, 15:51
Сообщения: 6055
Карма: 244
про коннекты - чота вряд ли в них какая-то инфа о TZ хранится

_________________
I'm clever. I've got a computer.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 ноя 2014, 13:39 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Ну у меня других объяснений нет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 ноя 2014, 14:52 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4494
Откуда: Уфа, Россия
Карма: 187
столбец lu - last update - дата последней правки записи т.е. фактически now(), на час меньше, чем dt...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 ноя 2014, 15:06 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
skn писал(а):
столбец lu - last update - дата последней правки записи т.е. фактически now(), на час меньше, чем dt...


lu хранит время в utc и выводит время c учетом текущей временной зоны. dt - то что записалось в локальном времени на тот момент.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 ноя 2014, 16:09 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
А что такое "Локальное время"?

Запросы биллинг делает такие:
Код:
INSERT INTO contract_logon_last SET cid=?, dt=now(), n=0, ip=?;
UPDATE contract_logon_last SET dt=now(), n=0, ip=? WHERE cid=?;


Т.е. now() отдаёт такое время, выходит.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 ноя 2014, 16:18 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
А что такое "Локальное время"?



вот тут про разницу datetime и timestamp
http://habrahabr.ru/post/61391/

Так у вас получается dt и now () правильно выдает, а lu показывает на час меньше чем нужно ? А часовые пояса точно обновились, а mysql перезагружался после этого ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 ноя 2014, 19:28 
Не в сети
Разработчик

Зарегистрирован: 07 апр 2007, 23:51
Сообщения: 4494
Откуда: Уфа, Россия
Карма: 187
to Cromeshnic
у вас какая версия и билды?
29 октября выкладывали обновление с исправлением ошибки вычисления времени dt.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 07 ноя 2014, 07:19 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
stark писал(а):
Так у вас получается dt и now () правильно выдает, а lu показывает на час меньше чем нужно ? А часовые пояса точно обновились, а mysql перезагружался после этого ?

Наоборот.
Вот тут текущее время - 10:17, now() у меня выдаётся корректно, а в dt - время из будущего:
Код:
mysql> SELECT * FROM contract_logon_last where dt>now();
+---------------------+--------+---------------------+---+---------------+
| lu                  | cid    | dt                  | n | ip            |
+---------------------+--------+---------------------+---+---------------+
| 2014-11-06 09:28:31 | 212541 | 2014-11-06 10:33:49 | 0 | x.x.x.x |
+---------------------+--------+---------------------+---+---------------+
1 row in set (0.01 sec)

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2014-11-06 10:17:33 |
+---------------------+
1 row in set (0.00 sec)


Вчера перезагрузил BGBillingServer, посмотрим.
TZ на хостах, в Java поменяли. В MySQL поменяли попозже и не перезагружали (вроде не потребовалось, т.к. now() стало нормально выдавать)

Сервер: вер. 5.2 сборка 1611 от 13.10.2014 18:22:56
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.6.0_22


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 07 ноя 2014, 12:21 
Не в сети
Разработчик

Зарегистрирован: 08 ноя 2007, 01:05
Сообщения: 8343
Откуда: Уфа
Карма: 238
Cromeshnic писал(а):
stark писал(а):
Так у вас получается dt и now () правильно выдает, а lu показывает на час меньше чем нужно ? А часовые пояса точно обновились, а mysql перезагружался после этого ?

Наоборот.
Вот тут текущее время - 10:17, now() у меня выдаётся корректно, а в dt - время из будущего:
Код:
mysql> SELECT * FROM contract_logon_last where dt>now();
+---------------------+--------+---------------------+---+---------------+
| lu                  | cid    | dt                  | n | ip            |
+---------------------+--------+---------------------+---+---------------+
| 2014-11-06 09:28:31 | 212541 | 2014-11-06 10:33:49 | 0 | x.x.x.x |
+---------------------+--------+---------------------+---+---------------+
1 row in set (0.01 sec)

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2014-11-06 10:17:33 |
+---------------------+
1 row in set (0.00 sec)


Вчера перезагрузил BGBillingServer, посмотрим.
TZ на хостах, в Java поменяли. В MySQL поменяли попозже и не перезагружали (вроде не потребовалось, т.к. now() стало нормально выдавать)

Сервер: вер. 5.2 сборка 1611 от 13.10.2014 18:22:56
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.6.0_22


Т.е у вас оба времени не правильных. lu и dt . Причем разница не кратна часу. Мистика однако.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 07 ноя 2014, 12:38 
Не в сети
Клиент
Аватара пользователя

Зарегистрирован: 20 апр 2009, 12:03
Сообщения: 3092
Откуда: Иркутск
Карма: 338
Сегодня вроде нет таких:

mysql> SELECT * FROM contract_logon_last where dt>now();
Empty set (0.01 sec)


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 16 ] 

Часовой пояс: UTC + 5 часов [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
POWERED_BY
Русская поддержка phpBB
[ Time : 0.077s | 48 Queries | GZIP : On ]