Декабрь 2011 г. аптайм 98.94%

Пора подводить итоги 2011 года. Так, с чего бы начать... Начнем с худшего хостинга 2011 года, им был признан - гремучая смесь низкой стоимости, ненадежности и хамства. На порядок выше, но все же хуже остальных хостингов пришлось признать и . И если в случае с ТагХостингом все более или менее предсказуемо - этот хостинг никогда не отличался стабильностью, то что произошло с ISPserver мне лично не до конца ясно. Дело в том, что тестируемый аккаунт на хостинге ISPserver находится на тарифе "облачный хостинг", что подразумевает повышенную стабильность по сравнению с обычным хостингом, но никак не пониженную. Хочется верить, что холдинг ISP наладит стабильную работу в новом году - хорошая компания и продукты выводит на рынок интересные. Ну вот и все - всех с наступившим, хороших праздников!

Ноябрь 2011 г. аптайм 99.67%


Октябрь 2011 г.


Практически весь октябрь хостинг продолжал чувствовать себя очень нестабильно, это было связано с полной неразберихой, которая творится у холдинга ISPserver - внезапные переносы на новые сервера и потеря данных о доменах в панели управления. На втором месте по худшему аптайму октября оказался хостинг - он был недоступен 27 часов, в процентах его аптайм составил 96.33%.
Из нового: В этом месяце мы подключили к системе тестирования на аптайм компанию , которая является одним из лидирующих на российском рынке регистраторов доменов. Около года назад стала предоставлять хостинг и насколько успешно - узнаем уже скоро. Первые результаты будут доступны в начале декабря. Что же касается - ноябрьский UpTime стал для него последним - этой компании присвоен статус "черного хостинга" за хамство технической поддержки и крайне негативную оценку пользователей (почитайте чтобы убедиться), и в связи с этим была она была исключена из рейтинга хостинг компаний.

Сентябрь 2011 г. тестирование Reg.Ru не проводилось


В сентябре что-то совершенно "нездоровое" творилось с - наш тестовый сайт был перенесен на другой сервер, а домен полностью перестал откликаться - как позже выяснилось, информация о нем вовсе исчезла из панели управления, а служба поддержки только развела руками, мол так и было. Грустно товарищи, что такое случается с крупным холдингом - ведь это не хостинг-однодневка. В итоге ISPserver был недоступен 40 часов, его аптайм 94.35%. В лузерах сентября также оказались хостинги и с результатами 98.08% и 98.55% соответственно.

Август 2011 г. тестирование Reg.Ru не проводилось


Август подошел к концу, и пора подводить итоги: два новых хостинга из США показали хорошие результаты: - 99.65% и - 99.91%. Совсем скоро эти хостинги будут подключены к нашему тестированию на быстродействие и скорость скачивания. Что касается худших - это московская площадка , она была недоступна 19(!) часов (97.47%) и c результатом 99.00% (7 часов "отключки").

Июль 2011 г. тестирование Reg.Ru не проводилось


В Июле мы добавили к тестированию на аптайм два : безлимитный и тяжеловес - мировой лидер по регистрации доменов. Первые результаты буду доступны в августе - посмотрим, как обстоят дела со стабильностью у данных площадок. Что касается худших хостинг-компаний в июле - ими стали две компании: - 95.04% (36 часов простоя, стабильность очень низкая) и московская хостинг-площадка со схожим результатом - 95.17%.

Июнь 2011 г. тестирование Reg.Ru не проводилось


Июнь выдался жарким, это отразилось на тестируемых площадках. Разбор полетов начнем с (он же ) - его аптайм за июнь составил 90.13%. Столь грустные цифры обусловлены тем, что у были недоступны дублирующие/технические адреса доменов (вида http://ДОМЕН.fatcow.com), а статистику мы ведем именно по ним. Сами же домены в этот момент были доступны, поэтому данная проблема сказалась только на тех, кто тестировал свои сайт по временному адресу.
Из "полноценных" оутсайдеров в очередной раз открывает тройку худших хостинг с результатом 98.08% (14 часов простоя), за ним расположились бюджетные хостинги (99.72% - 9 часов недоступности) и , который не работал 6 часов (аптайм 99.14%).

Май 2011 г. тестирование Reg.Ru не проводилось


Подводя итоги мая, можно сказать, что все сервера работали стабильно за исключением одного - это московская площадка (он же ), по данным статистики его аптайм составил 98.17% (более 13 часов простоя). Судя по предыдущему месяцу эта "стабильная нестабильность" московского хостинга начинает входить в привычку. Посмотрим, что будет в следующем месяце!

Апрель 2011 г. тестирование Reg.Ru не проводилось


Закончился апрель - пришло время подводить итоги тестов на аптайм. Худший результат показал московский датацентр , его UpTime составил 99.08% (7 часов простоя), за ним идут хостинги и - 99.17% (6 часов простоя).


Март 2011 г. тестирование Reg.Ru не проводилось


Март прошел без происшествий - в мире хостинга все было спокойно. Кстати ровно год назад произошел пожар в крупнейшем датацентре Украины, в результате которого были недоступны десятки тысяч украинских сайтов (более того, часть пользователей потеряли все свои данные, так как недобросовестные хостинг-компании хранили резервные копии в том же датацентре). На сегодняшний день можно констатировать тот факт, что

Январь 2011 г. тестирование Reg.Ru не проводилось


Начался второй месяц 2011 года, что нового произошло? Январь прошел тихо и спокойно, все сервера работали стабильно - серьезных аварий у тестируемых хостингов не было, чуть хуже остальных проявил себя , его результат работоспособности за Январь 2011 года 98.73% (около 10 часов простоя).
Так же мы удалили из рейтинга (sprinthost.ru). Причиной тому стала назойливость администрации хостинга - очень уж они хотели удалить негативный отзыв, который оставил один из их бывших клиентов (отзыв №3, см. на странице

На хостинге Linux

ISPmanager

u1234567 на ваш логин хостинга):

AddHandler fcgid-script .php .phtml .html .htm FCGIWrapper /var/www/u1234567/data/php-bin/php .php FCGIWrapper /var/www/u1234567/data/php-bin/php .phtml FCGIWrapper /var/www/u1234567/data/php-bin/php .html FCGIWrapper /var/www/u1234567/data/php-bin/php .htm

cPanel

В каталоге сайта создайте файл с названием .htaccess или просто откройте его, если файл уже существует. Добавьте в файл следующие строки (исправьте u1234567 на ваш логин хостинга):

AddHandler fcgid-script .php .phtml .html .htm FCGIWrapper /var/www/u1234567/php-bin/php .php FCGIWrapper /var/www/u1234567/php-bin/php .phtml FCGIWrapper /var/www/u1234567/php-bin/php .html FCGIWrapper /var/www/u1234567/php-bin/php .htm

Parallels Plesk

В каталоге сайта создайте файл с названием .htaccess или просто откройте его, если файл уже существует. Добавьте в файл следующие строки (исправьте u1234567 на ваш логин хостинга):

AddHandler fcgid-script .php .phtml .html .htm FCGIWrapper /var/www/vhosts/u1234567.plsk.regruhosting.ru/php-bin/php .php FCGIWrapper /var/www/vhosts/u1234567.plsk.regruhosting.ru/php-bin/php .htm FCGIWrapper /var/www/vhosts/u1234567.plsk.regruhosting.ru/php-bin/php .html FCGIWrapper /var/www/vhosts/u1234567.plsk.regruhosting.ru/php-bin/php .phtml

Parallels Plesk Onyx 17

В каталоге сайта создайте файл с названием .htaccess или просто откройте его, если файл уже существует. Добавьте в файл следующие строки:

AddHandler fcgid-script .php .phtml .html .htm FCGIWrapper /var/www/cgi-bin/cgi_wrapper/cgi_wrapper .php FCGIWrapper /var/www/cgi-bin/cgi_wrapper/cgi_wrapper .phtml FCGIWrapper /var/www/cgi-bin/cgi_wrapper/cgi_wrapper .html FCGIWrapper /var/www/cgi-bin/cgi_wrapper/cgi_wrapper .htm

Если данное решение не поможет, используйте следующую конструкцию:

AddType application/x-httpd-php .php AddHandler php-script .html

На хостинге Windows

В каталоге сайта создайте файл с названием web.config или просто откройте его, если файл уже существует. Добавьте в файл следующие строки:

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

Существует несколько способов создания регистрации и авторизации пользователей , но в этой статье я разберу свой любимый - через механизм сессий или cookie.

Первым делом, если Вы хотите сделать регистрацию у себя на сайте , то необходимо понимать, где будут храниться данные о пользователях. Можно хранить в обычном текстовом файле, в XML-файле , либо в базе данных. Первые два варианта - очень опасные, поэтому не рекомендую Вам ими пользоваться. А вот третий вариант - хранение информации о пользователях в базе данных - самый популярный, и именно этим способом хранения информации я советую Вам пользоваться.

С местом хранения определились. Теперь перейдём непосредственно к алгоритму авторизации :

  1. Создать форму регистрации на HTML .
  2. Получить данные из формы в скрипте-обработчике.
  3. Проверить полученные данные, и если они некорректны, то сделать редирект обратно на форму регистрации.
  4. Если данные корректны, то записать их в базу данных.

Вот и весь процесс регистрации пользователя на сайте . То есть регистрация - это сохранение информации о пользователе на сайте.

Дальнейшим пунктом является авторизация пользователя на сайте , однако, прежде чем к нему переходить, расскажу об одном важном моменте в форме регистрации - пароле. Я Вам настоятельно рекомендую не хранить пароли в открытом виде (например так, "123456 "). Обязательно их шифруйте, хотя бы с помощью функции md5() . И в базе данных храните именно зашифрованный пароль.

Теперь авторизация. Первое, что Вы должны понять - это то, что информация об авторизации должна где-то храниться. Самый простой вариант - это хранение информации в сессии (или в cookie ). А теперь алгоритм:

  1. Создать форму авторизации пользователя на HTML , куда пользователь должен будет ввести свой логин и пароль.
  2. В скрипте-обработчике принять данные от пользователя. Если Вы меня послушались, и храните шифрованные пароли в базе данных, то сначала шифруйте полученный пароль. Если же в базе данных лежат открытые пароли, то шифровать не надо.
  3. Проверить правильность введённых данных, и если логин и пароль совпадают с существующим пользователем в базе данных, то записываете в cookie или сессию информацию с логином и шифрованным паролем (либо открытым паролем, если Вы его не шифровали).
  4. Если логин и/или пароль введены неверно, то делать редирект обратно на форму авторизации.

Теперь у Вас есть необходимая информация об авторизации пользователя , которая хранится в его cookie или на сервере (если сессия). Фактически, теперь Вам нужно эту информацию проверять на каждой странице сайта и сверять её аналогично проверке формы авторизации. То есть считываете из cookie (сессии) логин и пароль, и проверяете его. Если они верные, то показываете одну страницу (для зарегистрированных пользователей), а если неверные, то показываете другую страницу (для гостей).

И последнее. Как делается кнопка "Выход "? Очень просто. При нажатии на эту кнопку, стираются cookie , либо сессия. Таким образом, пользователь автоматически вылетает с сайта.

Как видите, всё элементарно, но при реализации этого алгоритма у Вас обязательно возникнет множество вопросов. Например, что делать при регистрации пользователя, логин которого уже имеется в базе данных. Реализация различных проверок входных данных, реализация проверки существования e-mail и прочее - всё это является достаточно сложным, если Вы делаете это в первый раз. Однако, самый сок я выдал. Если будут вопросы при реализации, то спрашивайте либо на форуме, либо в комментариях.