Список ожидаемых дополнений

[admin]

По Директи да делайте.

Сделаю в каком-либо из билдов.

 

По счетам раньше у неоплаченных счетов ставилось то же число, что и выставление и не было проблем. Какой смысл в 1970 году?

 

По базе - это нуль. А php, при конвертации, начинает считать нуль как 1 января 1970 года. Это же же лучше, чем пустота, т.к. при наличии якобы записи о 1970 году можно ее вручную изменить по шаблону.

 

В настройках доменной зоны указан какой-либо регистратор?

Регистрация доменов в данной зоне происходит автоматически?

 

Нет, не указан.

Регистрация доменов вручную.

 

Проверил на домене .com.ua без указанного регистратора, на главную админки добавилось

USER_ID Рег. Домена x 1 DOMEN_ID

[admin]

По Директи да делайте.

 

Сделал для сегодняшней сборки.

Из-за особенностей регистратора directi алгоритм работы данной ф-ии таков:

1. Getting the Default Contact Details http://manage.resellerclub.com/kb/answer/794

2. Данные в этом главном contactid изменяются согласно http://manage.resellerclub.com/kb/answer/791

3. В домене изменяются registrar, billing, tech и admin контакты на главный согласно http://manage.resellerclub.com/kb/answer/777

[admin]

Хотел попросить функционал смены главного домена перенести в Мой аккаунт - Данные по серверу, на данный момент расположение не логичное, многие клиенты жалуются...

 

В каком-либо из билдов добавлю в раздел данных по серверу ссылку на изменение главного домена на странице изменения данных по аккаунту.

 

Добавил в сегодняшней сборке. Архив обновил.

[Vladimir812]

Изменение по действиям с доменами под секретный ответ уже делали?

[admin]

Нет. Делать не буду, т.к. не считаю необходимым.

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

[Vladimir812]

Я не про ДНС, а про смену данных рушек через биллинг, а также TLD после последних изменений.

 

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

[Vladimir812]

Еще есть небольшая просьба. Сделайте какую нибудь настройку для защиты от взлома, где можно было бы указать список доменов, на которые защита бы не распространялась.

Пример- биллинг на order.bpanel.ru, форма входа на bpanel.ru. При входе всегда получим защиту от взлома.

[Vladimir812]

Клиенты стали жаловаться на неправильную работу функции восстановления паролей от биллинг аккаунтов. В некоторых случаях при нажатии на ссылку в письме восстановления клиент получает снова такое же письмо вместо письма с паролем. Прошу проверить и поправить.

[Vladimir812]

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

[admin]

Я не про ДНС, а про смену данных рушек через биллинг, а также TLD после последних изменений.

Так а что в рушках-то поменять можно? емайл и телефон? Как и писал выше, лучше узнать о взломе на основе подобных малых неприятностей, чем взломщик будет и дальше иметь доступ к аккаунту.

 

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

 

Сотрудник прописан в конкретной услуге, подключенной после ноября?

 

Для дальнейшего исследования проблемы необходимо следующее:

1. URL скрипта.

2. Данные доступа в админ-центр биллинга, проверка по IP адресу должна быть отключена;

3. Данные доступа на FTP с биллингом;

4. URL темы на форуме forum.advanta.org;

5. Номер дополнительной услуги, которая не отображается в статистике по сотруднику.

На admin @ advanta.org

 

Еще есть небольшая просьба. Сделайте какую нибудь настройку для защиты от взлома, где можно было бы указать список доменов, на которые защита бы не распространялась.

Пример- биллинг на order.bpanel.ru, форма входа на bpanel.ru. При входе всегда получим защиту от взлома.

 

Сделал для новой сборки: админка -> настройки -> безопасность -> Причислять к нашим доменам следующие (по одному в строку).

 

Клиенты стали жаловаться на неправильную работу функции восстановления паролей от биллинг аккаунтов. В некоторых случаях при нажатии на ссылку в письме восстановления клиент получает снова такое же письмо вместо письма с паролем. Прошу проверить и поправить.

 

Для дальнейшего исследования проблемы необходимо следующее:

1. URL скрипта.

2. Данные доступа в админ-центр биллинга, проверка по IP адресу должна быть отключена;

3. Данные доступа на FTP с биллингом;

4. URL темы на форуме forum.advanta.org;

5. Номер аккаунта клиента.

На admin @ advanta.org

 

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

 

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

 

 

Архив обновил.

[Vladimir812]

По услугам разобрался.

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

 

Просьба для не TLD доменов добавить к изменениям и изменения в биллинге, также как сделано для TLD сейчас. Как выяснилось, для многих клиентов важно кто указан в биллинге владельцем домена

[admin]

Что именно не изменяется и как не изменяется и как должно изменяться (с XXX на YYY например).

В какой доменной зоне и у какого регистратора нужно внести исправления/изменения?

[Vladimir812]

Для доменов TLD при изменении данных они меняются и в биллинге для домена и у регистратора. Для наших зон через биллинг можно тоже менять данные у регистратора, но клиент не может изменить данные в самом биллинге по домену (владелец).

 

Также просьба сделать логирование любых таких изменений, если не сделано еще.

[admin]

В "Ваших зонах" - это домены третьего уровня в доменных зонах хостера? Какой смысл менять там что-либо, whois по таким доменным зонам ведь все равно в 99% случае не существует (хостер его не поднимает у себя на сервере).

[Vladimir812]

Я имел ввиду .ru, .рф как наши зоны

[admin]

У доменов .RU и .РФ просто программным запросом изменить данные нельзя. Нужно лезть на сайт регистратора, узнавать какие документы, подпись на которых заверена нотариусом, нужны и куда их отправлять.

[admin]

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

 

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

1. Исключается возможность ошибочного удаления аккаунта клиентом и последующей траты времени хостером на восстановление из бекапа.

2. Клиенту или хостеру может понадобиться какая-либо информация из аккаунта.

Смысла в формированном уменьшении срока хранения заблокированного аккаунта на сервере - не вижу.

[Vladimir812]

У доменов .RU и .РФ просто программным запросом изменить данные нельзя. Нужно лезть на сайт регистратора, узнавать какие документы, подпись на которых заверена нотариусом, нужны и куда их отправлять.

Почтовый адрес, телефон, sms телефон, факс и email можно менять без всяких доков.

[Vladimir812]

По модулю csf немного инфы.

Если IP адрес находится в gallow или gignore, то при запросе инфы из биллинга видим ошибку модуля csf.

Если IP находится ,например, в списке dshield, то получаем, что он заблокирован и тоже получаем, если он в gallow, хотя по факту он не может блокироваться в данной ситуации.

[Vladimir812]

Опять по CSF. Если IP присутствует в правилах iptables, даже в качестве доверенного, то при проверке биллингом получаем - IP заблокирован на сервере.

[Vladimir812]

Опять всплывает проблема с комбинированными доменами. При заполнении заказа, если указать домен вида домен.com, то получим ошибку, хотя в безопасности разрешены все символы и до и после точки. Прошу поправить.

[admin]

У доменов .RU и .РФ просто программным запросом изменить данные нельзя. Нужно лезть на сайт регистратора, узнавать какие документы, подпись на которых заверена нотариусом, нужны и куда их отправлять.

Почтовый адрес, телефон, sms телефон, факс и email можно менять без всяких доков.

 

У .RU и .РФ и т.п. доменов эти данные итак можно изменять через биллинг: запрос на изменение данных от биллинга отправляется к API регистратора.

 

 

По модулю csf немного инфы.

Если IP адрес находится в gallow или gignore, то при запросе инфы из биллинга видим ошибку модуля csf.

Если IP находится ,например, в списке dshield, то получаем, что он заблокирован и тоже получаем, если он в gallow, хотя по факту он не может блокироваться в данной ситуации.

 

Не особо знаком, что такое gallow и gignore в csf. Полагаю, что это некие глобальные настройки.

Биллинг проверяет данные только на основе страниц, отображаемых в WHM. Доступа глобальным настройкам файроволла или т.п. BPanel не имеет.

 

Опять по CSF. Если IP присутствует в правилах iptables, даже в качестве доверенного, то при проверке биллингом получаем - IP заблокирован на сервере.

 

Аналогично.

 

Опять всплывает проблема с комбинированными доменами. При заполнении заказа, если указать домен вида домен.com, то получим ошибку, хотя в безопасности разрешены все символы и до и после точки. Прошу поправить.

 

Какая именно ошибка?

Что указано в настройках безопасности по допустимым символам в домене?

Что указано в настройках доменной зоны по допустимым символам в домене?

Что вводится в поле домена?

[Vladimir812]

В WHM CSF IP нигде не значится как блокированный, биллинг утверждает, что заблокирован. Если IP числится в спец списках, да глобальные настройки, то просто выдается вывод таблиц iptables где есть данный IP, при этом говоря - ошибка работы с модулем CSF.

 

Комбинированные домены - вводим домен.com

В настройках безопасности до и после точки - a-zа-я0-9-ё

Такую зону мы не регистрируем, видимо от этого и ошибка - неверный формат домена.

 

Также перестал отрабатывать usage.php, не передается параметр IP:

 

 

php /home/****/www/admin/usage.php ip=**.***.***.* go=start

Sorry, <b></b> is a wrong IP Address

 

При этом в админке все работает, IP прописывается именно тот, что в настройках сервера в биллинге.

[Vladimir812]

По usage вопрос решен, остальное актуально.

[admin]

В WHM CSF IP нигде не значится как блокированный, биллинг утверждает, что заблокирован. Если IP числится в спец списках, да глобальные настройки, то просто выдается вывод таблиц iptables где есть данный IP, при этом говоря - ошибка работы с модулем CSF.

 

Нужна информация для возможности воспроизведения ошибки.

 

Для дальнейшего исследования проблемы необходимо следующее:

1. URL скрипта.

2. Данные доступа в админ-центр биллинга, проверка по IP адресу должна быть отключена;

3. Данные доступа на FTP с биллингом;

4. URL темы на форуме forum.advanta.org;

5. Данные доступа в реселлерскую часть панели управления сайтом;

6. IP, на который ругается.

На admin @ advanta.org

 

Комбинированные домены - вводим домен.com

В настройках безопасности до и после точки - a-zа-я0-9-ё

Такую зону мы не регистрируем, видимо от этого и ошибка - неверный формат домена.

 

На адванте например без проблем работает со следующими настройками:

Глобальные до точки: a-zа-яё0-9єіїґ-

После точки: a-zа-я0-9-

В настройках доменной зоны, в которой разрешены русские символы: a-zа-яё0-9-