Всякое бывает. Может и канал просел где-то на пути.
Как измеряете?
Саппорт на английском. Я не знаю, кому они там 10 дней отвечали. Мне, когда аккаунт был со стандартным уровнем поддержки отвечали от 3 до 24 часов.
Про отключение сервера при абузе, смотря что. Если дп, то могут. Если простая жалоба, то дают исходя из данной надписи: "You can report an abuse from out network with this form. You'll receive an email when your alert will be closed (within 24 to 48 hours)." от 24 до 48 часов.
Их ценовая политика серверов вполне соответствует поддержке, включенной по умолчанию к ним.
А критический уровень обслуживания в принципе и не будет заметен тем, кто берет у них сервера пачками.
А в целом, если железо у них работает исправно, то зачем Вам поддержка? KVM фактически на всех серверах, удобная панель, полная статистика, заказ IP адресов в автоматическом режиме. Для чего поддержка-то? :) Настраивать сервер Вам они не будут и при критическом уровне обслуживания, мне кажется. Для этих целей лучше нанимать отдельного администратора...
Успехов, надеюсь всё разрешится.
У них раньше, до обновления сайта писалось в биллинге, что на бизнес уровне в течении 4 часов, но сейчас это пропало.
Мы, кстати, когда переносили к ним резервные копии, грузили канал до 300 мбит\с в течении нескольких часов, тоже ловили странность, в разделе сервера нам вешали надпись, что сервер заблокировал за подозрительную активность. Но пока писали тикет - заходим, уже нет надписи и всё работает.
Поддержка через несколько часов просто ответила, что сервер работает. Причины не объяснила... Там два варианта блокировки было, либо за долговременную нагрузку канала, либо мы в это время подключали дополнительные IP и игрались с MAC-адресами, скорее всего из-за этого и блокировало на время.
При бизнес уровне обслуживания, Вам должны отвечать в течении 24-х часов.
Для подключения DDoS защиты, с Вами должен был связаться техник ДЦ. Я писал об этом в теме. Скорее всего, Вам не подключили расширенную защиту от DDoS и активна стандартная, которой как таковой нет. Она защищает только от мелкого флуда.
Это палка о двух концах. Вам необходимо хранить либо данные базы данных, либо данные администратора. Пользователя ведь как-то надо создать в биллинге :) Есть еще идеи, но озвучивать их не буду, чтобы не возникли еще дискуссии...
И мое мнение, лучше хранить данные администратора, чем данные базы, если рассматривать два этих варианта... Но, как сказал, уважаемый Павел: "о деталях можно спорить"...
То, что я предложил, это моя первая идея, которая появилась относительно недавно. Я её не продумывал, и не прорабатывал. Так сказать, наброски. Понятно, что при реализации, что-то может быть переработано.
То, что нет в API, можно реализовать самостоятельно. WHMCS берет данные из БД, если в API нет метода, можно сделать это самостоятельно, прямым обращением в БД. Основные функции можно реализовать полностью на API, а как Вы сами сказали "не больно нужные" можно вовсе не реализовывать, либо реализовать по схеме выше - прямым обращением в БД.
Вы вновь упоминаете о пользователе администратора. Я вновь подчеркиваю, чем это небезопасно, чем Вас это смущает? Соединение происходит на стороне сервера, а не клиента. Клиент не узнает, имя пользователя администратора и его пароль.
Вы говорите полную ерунду. Как раз в случае моей схемы, взломщик не получит полный доступ к биллингу (конечно, если не передавать все используемые методы или пароль администратора через клиента).
Все методы, пароль и имя пользователя администратора взаимодействуют только на стороне сервера с биллингом. Злоумышленник максимум, что передаст опасные данные на API, даже если у нас не сработает фильтр. Каким образом он по Вашему получит ПОЛНЫЙ доступ к биллингу?
Чтобы получить доступ к биллингу, нужно вытащить из PHP файла заданные имя пользователя и пароль администратора. Вытащить адрес, где спрятан биллинг. Дальше, если вход только локальный, надо влить как-то свой скрипт, который будет делать локально запросы к биллингу. В добавок, в моем случае, если не делать прямые запросы к БД, то данные от неё хранить вовсе не надо. То есть, злоумышленник также не сможет получить доступ к БД биллинга.
Возможно мы не понимаем друг друга. Что Вы имеете под пользовательским API?
Я предлагал такую схему, поясню на примере оформления заказа.
1. Клиент заполняет на нашем сайте форму, где указывает домен, период оплаты и прочие необходимые данные.
2. Мы обрабатываем эти данные, если все нормально, но передаем их в безопасном виде на метод addorder самого биллинга: http://docs.whmcs.com/API:Add_Order
3. Клиенту отдаем страницу "Спасибо за заказ".
Клиент полностью работает с нашим сайтом и нашим скриптом. Он никак не доходит до биллинга WHMCS и понятия не имеет о его существовании.
Что в данном случае небезопасного? Поясните мне, пожалуйста.
Хм, видимо у меня, как программиста, иные взгляды. Код WHMCS закрыт - я его не вижу, поправить ничего нельзя. Фактически у меня отняли руки.
В итоге, как альтернатива, это своя "обертка", где я буду уверен, что данные будут передаваться к биллингу на API в отфильтрованном виде.
Что Вас смущает, что API работает от имени администратора? То, что пароль будет хранится в открытом виде в PHP файле? Данные доступа к базе данных тоже хранятся в открытом виде в конфигурационном фале, если получить доступ сразу к БД, то проблема мне кажется даже слаще будет.
Не считаю, в общем, это проблемой.
