Beget ошибка 403

Apache — самый распространённый HTTP-сервер. Распространяется бесплатно, включая исходные тексты. Поддерживаются сценарии на CGI (включая FastCGI), PHP, Perl, Java. Аутентификация — базовая, message-digest, TLS (SSL). С апреля 1996 это самый популярный HTTP-сервер в Интернете, в августе 2007 года он работал на 51% всех веб-серверов.

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

.htaccess является подобием httpd.conf с той разницей, что действует только на каталог, в котором располагается, и на его дочерние каталоги. Возможность использования .htaccess присутствует в любом каталоге пользователя.

Файл .htaccess может быть размещен в любом каталоге сайта. Директивы этого файла действуют на все файлы в текущем каталоге и во всех его подкаталогах (если эти директивы не переопределены директивами нижележащих файлов .htaccess).

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

• Директивы простого перенаправления (редирект);
• Директивы сложного перенаправления (mod_rewrite);
• Индексные страницы;
• Обработка ошибок;
• Кодировка;
• Управление доступом;
• Паролирование директорий;
• Указание опций PHP.

Список всех доступных директив можно посмотреть тут.

Директивы простого перенаправления (редирект)

Наиболее часто используемые и наиболее сложные директивы .htaccess. Предположим, мы хотим при запросе нашего сайта переадресовать пользователя на другой URL. Для этого нам необходимо в корневую директорию сайта добавить файл .htaccess со следующим содержимым:

Redirect / http://www.example.com
# http://www.example.com - URL, на который мы перенаправляем запросы

Более сложный пример — мы хотим определенные страницы нашего сайта переадресовывать на другие сайты:

Redirect /linux http://www.linux.org
Redirect /linux/download.html http://www.linux.org/dist/download_info.html
Redirect 301 /kernel http://www.linux.org

Теперь при обращении к http://mysite.ru/linux будет открываться http://www.linux.org, а при обращении к http://mysite.ru/linux/download.html будет http://www.linux.org/dist/download_info.html . В последнем примере WEB-сервер будет передавать код 301, что означает «документ перемещен постоянно».

Синтаксис команды Redirect выглядит следующим образом:

Redirect [status] URI_LOCAL URL_REDIRECT

status : необязательное поле, определяет код возврата. Допустимые значения:

    * permanent (301 — документ перемещен постоянно)
    * temp (302 — документ перемещен временно)
    * seeother (303 — смотрите другой)
    * gone (410 — убран)

URI_LOCAL : локальная часть URL запрашиваемого документа.

URL_REDIRECT : URL, куда должен быть выполнен редирект.

Директива RedirectMatch аналогична директиве Redirect за исключением того, что в RedirectMatch возможно использование регулярных выражений, что, несомненно, может быть удобно в некоторых условиях. Например, для организации передачи параметров скрипту в теле URL:

RedirectMatch /(.*)/(.*)/index.html$ http://mysite.ru/script.php?par1=$1&par2=$2

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

В регулярном выражении можно использовать любые печатные символы и пробел, но часть символов имеет особое значение:

• Круглые скобки () используются для выделения групп символов. В дальнейшем к ним можно обращаться по номеру.
• Символ ^ обозначает начало строки.
• Символ $ обозначает конец строки.
• Символ . обозначает любой символ.
• Символ | обозначает альтернативу. Например, выражения «A|B» означают «A или B».
• Символ ? ставится после символа (группы), который может как присутствовать, так и отсутствовать.
• Символ * ставится после символа (группы), который может отсутствовать или присутствовать неограниченное число раз подряд.
• Символ + действует аналогично символу * с той лишь разницей, что предшествующий ему символ обязательно должен присутствовать хотя бы один раз.
• Квадратные скобки [] используются для перечисления допустимых символов.
• Квадратные скобки [^] используются для перечисления недоступных символов.
• Символ ставится перед спецсимволами, если они нужны в своем первозданном виде.
• Все, что расположено после символа ‘#‘, считается комментарием.

Это все основные примитивы, с помощью которых можно построить любое регулярное выражение.

Директивы сложного перенаправления (mod_rewrite)

Модуль mod_rewrite, имеющийся в составе Apache — это мощнейшее интеллектуальное средство преобразования URL-адресов. С ним возможны почти все типы преобразований, которые могут выполняться или нет в зависимости от разных условий, факторов.

Данный модуль представляет собой основанный на правилах механизм (синтаксический анализатор с применением регулярных выражений), выполняющий URL-преобразования на лету. Модуль поддерживает неограниченное количество правил и связанных с каждым правилом условий, реализуя действительно гибкий и мощный механизм управления URL. URL-преобразования могут использовать разные источники данных, например, переменные сервера, переменные окружения, заголовки HTTP, время и даже запросы к внешним базам данных в разных форматах для получения URL нужного Вам вида.

Директива RewriteCond определяет условие, при котором происходит преобразование. RewriteCond определяет условия для какого-либо правила. Перед директивой RewriteRule располагаются одна или несколько директив RewriteCond. Следующее за ними правило преобразования используется только тогда, когда URI соответствует условиям этой директивы, а также условиям этих дополнительных директив.

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

• $N — (0 <= N <= 9) предоставляющие доступ к сгруппированным частям (в круглых скобках!) шаблона из соответствующей директивы RewriteRule (единственной, следующей сразу за текущим набором директив RewriteCond).
• %N — (1 <= N <= 9) предоставляющие доступ к сгруппированным частям (в круглых скобках!) шаблона из соответствующей директивы RewriteCond в текущем наборе условий.
• %{NAME_OF_VARIABLE} — где NAME_OF_VARIABLE может быть одной из ниже приведенных переменных

Ниже приводится список всех доступных переменных %{NAME_OF_VARIABLE} с их кратким описанием.

• HTTP_USER_AGENT — Содержит информацию о типе и версии браузера и операционной системы посетителя.
• HTTP_REFERER — Приводится адрес страницы, с которой посетитель пришёл на данную страницу.
• HTTP_COOKIE — Список COOKIE, передаваемых браузером.
• HTTP_FORWARDED — Cодержит IP-адрес прокси-сервера или сервера балансировки нагрузки.
• HTTP_HOST — Адрес сервера, например, beget.com .
• HTTP_ACCEPT — Описываются предпочтения клиента относительно типа документа.
• REMOTE_ADDR — IP-адрес посетителя.
• REMOTE_HOST — Адрес посетителя в нормальной форме — например, rt99.net.ru .
• REMOTE_IDENT — Имя удаленного пользователя. Имеет формат имя.хост, например, kondr.www.rtt99.net.ru
• REMOTE_USER — Тоже, что и REMOTE_IDENT, но содержит только имя. Пример: kondr
• REQUEST_METHOD — Позволяет определить тип запроса (GET или POST). Должен обязательно анализироваться, т.к. определяет дальнейший способ обработки информации.
• SCRIPT_FILENAME — Полный путь к веб-странице на сервере.
• PATH_INFO — Содержит в себе все, что передавалось в скрипт.
• QUERY_STRING — Содержит строчку, переданную в качестве запроса при вызове CGI скрипта.
• AUTH_TYPE — Используется для идентификации пользователя
• DOCUMENT_ROOT — Cодержит путь к корневой директории сервера.
• SERVER_ADMIN — Почтовый адрес владельца сервера, указанный при установке.
• SERVER_NAME — Адрес сервера, например, kondr.beget.com
• SERVER_ADDR — IP-адрес вашего сайта.
• SERVER_PORT — Порт, на котором работает Apache.
• SERVER_PROTOCOL — Версия HTTP протокола.
• SERVER_SOFTWARE — Название сервера, например, Apache/1.3.2 (Unix)
• TIME_YEAR, TIME_MON, TIME_DAY, TIME_HOUR, TIME_MIN, TIME_SEC, TIME_WDAY, TIME — Переменные, предназначенные для работы со временем в разных форматах.
• API_VERSION — Это версия API модуля Apache (внутренний интерфейс между сервером и модулем) в текущей сборке сервера, что определено в include/ap_mmn.h.
• THE_REQUEST — Полная строка HTTP-запроса, отправленная браузером серверу (т.е., «GET /index.html HTTP/1.1»). Она не включает какие-либо дополнительные заголовки отправляемые браузером.
• REQUEST_URI — Ресурс, запрошенный в строке HTTP-запроса.
• REQUEST_FILENAME — Полный путь в файловой системе сервера к файлу или скрипту, соответствующему этому запросу.
• IS_SUBREQ — Будет содержать текст «true», если запрос выполняется в текущий момент как подзапрос, «false» в другом случае. Подзапросы могут быть сгенерированы модулями, которым нужно иметь дело с дополнительными файлами или URI для того, чтобы выполнить собственные задачи.

Условие — это шаблон условия, т.е. какое-либо регулярное выражение, применяемое к текущему экземпляру «Сравниваемая Строка», т.е. «Сравниваемая Строка» просматривается на поиск соответствия Условию.

Помните, что Условие — это perl-совместимое регулярное выражение с некоторыми дополнениями:

• Вы можете предварять строку шаблона префиксом ‘!’ для указания несоответствия шаблону;
• ‘ <Условие’ (лексически меньше);
• ‘>Условие’ (лексически больше);
• ‘=Условие’ (лексически равно);
• ‘-d’ (является ли каталогом);
• ‘-f’ (является ли обычным файлом);
• ‘-s’ (является ли обычным файлом с ненулевым размером);
• ‘-l’ (является ли символической ссылкой);
• ‘-F’ (проверка существования файла через подзапрос);
• ‘-U’ (проверка существования URL через подзапрос).

Все эти проверки также могут быть предварены префиксом восклицательный знак (‘!’) для инвертирования их значения.

RewriteEngine включает или выключает работу механизма преобразования. Если она установлена в положение off, этот модуль совсем не работает. Заметьте, что по умолчанию настройки преобразований не наследуются. Это означает, что вы должны иметь RewriteEngine on директиву для каждого виртуального хоста, в котором вы хотите использовать этот модуль.
Синтаксис RewriteEngine выглядит следующим образом:

RewriteEngine on | off

# По умолчанию RewriteEngine off

Используйте для комбинирования условий в правилах OR вместо AND. Типичный пример — перенаправление запросов на поддомены в отдельные каталоги.

RewriteEngine on

RewriteCond %{REMOTE_HOST} ^mysubdomain1.* [OR]
RewriteCond %{REMOTE_HOST} ^mysubdomain2.* [OR]
RewriteCond %{REMOTE_HOST} ^mysubdomain3.*
RewriteRule ^(.*)$ ^mysubdomain_public_html/$1

RewriteCond %{REMOTE_HOST} ^mysubdomain4.*
RewriteRule ^(.*)$ ^mysubdomain4_public_html/$1

Для выдачи главной страницы какого-либо сайта, согласно «User-Agent:» заголовку запроса, Вы можете использовать следующие директивы:

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
RewriteRule ^$ /homepage.max.html [L]

RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
RewriteRule ^$ /homepage.min.html [L]

RewriteRule ^$ /homepage.std.html [L]

Для выдачи разных сайтов для разных браузеров, согласно «User-Agent:» заголовку запроса, Вы можете использовать следующие директивы:

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
RewriteRule ^(.*)$ /mozilla/$1 [L]

RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
RewriteRule ^(.*)$ /lynx/$1 [L]

RewriteRule ^(.*)$ /default/$1 [L]

Общий синтаксис директивы RewriteRule выглядит следующим образом:

RewriteRule Шаблон Подстановка [flag]

# flag - необязательное поле указывающее дополнительные опции

В подстановке вы можете использовать, в том числе, и специальные флаги путем добавления в качестве третьего аргумента директивы RewriteRule. Флаги — это разделённый запятыми следующий список флагов:

'redirect|R [=code]'
(вызывает редирект)

Префикс в Подстановке вида http://thishost[thisport]/ (создающий новый URL из какого-либо URI) запускает внешний редирект (перенаправление). Если нет никакого кода, в подстановке ответ будет со HTTP статусом 302 (ВРЕМЕННО ПЕРЕМЕЩЕН). Для остановки процесса преобразования вам также нужно написать флаг ‘L’.

'forbidden|F [=code]' 
(делает URL запрещенным)

Это делает текущий URL запрещённым, например, клиенту немедленно отправляется ответ с HTTP статусом 403 (ЗАПРЕЩЕНО). Используйте этот флаг в сочетании с соответствующими RewriteConds для блокирования URL по некоторым критериям.

'gone|G [=code]' 
(делает URL «мёртвым»)

Этот флаг делает текущий URL «мертвым», т.е., немедленно отправляется HTTP ответ со статусом 410 (GONE). Используйте этот флаг для маркировки «мертвыми» несуществующие более страницы.

'proxy|P [=code]' 
(вызвает прокси)

Этот флаг помечает подстановочную часть как внутренний запрос прокси и немедленно (т.е. процесс преобразования здесь останавливается) пропускает его через прокси-модуль. Используйте этот флаг для того, чтобы добиться более мощной реализации директивы ProxyPass, интегрирующей некоторое содержимое на удаленных серверах в пространство имён локального сервера.

'last|L [=code]' 
(последнее правило)

Остановить процесс преобразования на этом месте и не применять больше никаких правил преобразований. Используйте этот флаг для того, чтобы не преобразовывать текущий URL другими, следующими за этим, правилами преобразований.

'next|N [=code]' 
(следуюший раунд)

Перезапустить процесс преобразований (начав с первого правила). В этом случае URL снова сопоставляется неким условиям, но не оригинальный URL, а URL вышедший из последнего правила преобразования. Используйте этот флаг для перезапуска процесса преобразований, т.е. безусловному переходу на начало цикла.

'chain|C [=code]' 
(связь со следующим правилом)

Этот флаг связывает текущее правило со следующим (которое, в свою очередь, может быть связано со следующим за ним, и т.д.). Это имеет следующий эффект: если есть соответствие правилу, процесс продолжается как обычно, т.е. флаг не производит никакого эффекта. Если правило не соответствует условию, все следующие, связанные правила, пропускаются.

'type|T=MIME-тип [=code]'
(принудительно установить MIME тип)

Принудительно установить MIME-тип целевого файла в MIME-тип. К примеру, это можно использовать для имитации mod_alias директивы ScriptAlias, которая принудительно устанавливает для всех файлов внутри отображаемого каталога MIME тип равный «application/x-httpd-cgi».

'nosubreq|NS [=code]'
(используется только в случае не внутреннего подзапроса)

Этот флаг дает команду механизму преобразований пропустить директиву, если текущий подзапрос является внутренним подзапросом. К примеру, внутренние подзапросы в Apache происходят тогда, когда mod_include пытается получить информацию о возможных файлах по умолчанию для каталогов (index.xxx). При подзапросах это не всегда полезно и даже иногда вызывает проблему в работе набора директив преобразований. Используйте этот флаг для исключения некоторых правил.

'nocase|NC [=code]' 
(не учитывать регистр)

Это делает Шаблон нечувствительным к регистру, т.е. нет различий между ‘A-Z’ и ‘a-z’, когда Шаблон применяется к текущему URL.

'qsappend|QSA [=code]' 
(добавлять строку запроса)

Этот флаг указывает механизму преобразований на добавление, а не замену, строки запроса из URL к существующей, в строке подстановки. Используйте это когда вы хотите добавлять дополнительные данные в строку запроса с помощью директив преобразований.

'noescape|NE [=code]' 
(не экранировать URI при выводе)

Этот флаг не даёт mod_rewrite применять обычные правила экранирования URI к результату преобразования. Обычно, специальные символы (такие как ‘%’, ‘$’, ‘;’, и так далее) будут экранированы их шестнадцатиричными подстановками (‘%25’, ‘%24’, и ‘%3B’, соответственно); этот флаг не дает это делать.

Если в подкаталогах в .htaccess нет ни одной директивы модуля mod_rewrite, то все правила преобразования наследуются из родительского каталога.

При наличии в файле .htaccess каких-либо директив модуля mod_rewrite не наследуется ничего, а состояние по умолчанию выставляется таким же, как в главном конфигурационном файле веб-сервера (по умолчанию «off»). Поэтому, если нужны правила преобразования для конкретного каталога, то нужно еще раз вставить директиву «RewriteEngine on» в .htaccess для конкретного каталога.

При наследовании правил из верхних каталогов и добавлении к ним новых свойственных только данному каталогу — необходимо выставить в начале следующее: «RewriteEngine on» и «RewriteOptions inherit» — последняя директива сообщает серверу о продолжении.

Примеры использования mod_rewrite можно посмотреть тут.

Индексные страницы

Когда пользователь заходит на хост, например, http://gentoo.org, принято, что открывается индексный файл index.* , а при его отсутствии отображается либо содержимое каталога, либо отдается ошибка 403 FORBIDDEN (если отключена опция «просмотр директорий»).

За листинг файлов отвечает директива Indexes (показывать посетителю список файлов, если в выбранном каталоге нет файла index.html или его аналога).

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

# Запрет выдачи листинга пустого каталога
Options -Indexes

А чтобы выдавал листинг, нужно:

Если же понадобится разрешить просматривать список файлов, но чтобы при этом чаcть файлов определенного формата не отображалась, то запишем:

Выдает листинг каталога, т.е. его содержание со всем содержанием, за исключением файлов-скриптов PHP и Perl.

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

DirectoryIndex index.html index.shtml index.pl index.cgi index.php

Если же вы хотите что бы при обращении к каталогу открывался не index.html, а, например, файл htaccess.php или /cgi-bin/index.pl:

DirectoryIndex htaccess.php /cgi-bin/index.pl

Обработка ошибок

В ходе работы сервера иногда возникают ошибки, однако правильнее называть их не сбоями в работе сервера, а стандартными кодами возврата, оговоренными в стандарте HTTP_RFC2616. Вообще, в RFC ошибки называются «Status Codes», но мы их будем называть именно ошибками — так привычнее.

Код возврата — это трехзначное число, на основании которого можно судить о том, насколько успешно был обработан запрос. Код возврата начинающиеся на 1,2,3 считаются успешными, остальные причисляются к разряду ошибок.

Вот список ошибок 4xx и 5xx:

• 400 — Bad Request
• 401 — Unauthorized
• 402 — Payment Required
• 403 — Forbidden
• 404 — Not Found
• 405 — Method Not Allowed
• 406 — Not Acceptable
• 407 — Proxy Authentication Required
• 408 — Request Time-out
• 409 — Conflict
• 410 — Gone
• 411 — Length Required
• 412 — Precondition Failed
• 413 — Request Entity Too Large
• 414 — Request-URI Too Large
• 415 — Unsupported Media Type
• 500 — Internal Server Error
• 501 — Not Implemented
• 502 — Bad Gateway
• 503 — Service Unavailable
• 504 — Gateway Time-out
• 505 — HTTP Version not supported

При возникновении ошибки 4xx или 5xx посетитель Вашего сайта увидит в браузере сообщение от сервера, которое вряд ли можно назвать предельно понятным рядовому пользователю. Apache предоставляет возможность выдать вместо аскетичного технического текста, не изобилиющего деталями, свою страницу, где Вы можете человеческим языком объяснить пользователю, что произошло и что делать.

Пример переопределения страниц ошибок приведен ниже:

# содержание файла .htaccess:

ErrorDocument 404 http://bg10.ru/error/404.htm
ErrorDocument 403 http://bg10.ru/error/403.htm
ErrorDocument 400 http://bg10.ru/error/400.htm
ErrorDocument 500 http://bg10.ru/error/500.htm

# в случае ошибки "FORBIDDEN" показывается текстовое сообщение, которое
# обязательно должно начинаться с кавычки, кавычка в сообщении не выводится:

ErrorDocument 403 "Sorry can't allow you access today, 403 Status Codes Apache"

Более подробно об обработке ошибок можно прочитать в документации по Apache на странице «Custom error responses».

Кодировка

Иногда браузер пользователя не может корректно определить тип кодировки выдаваемого документа. Для решения этой проблемы используемая кодировка указывается в настройках Web-сервера Apache и заголовке передаваемого документа. Причем для корректного распознания эти кодировки должны совпадать. На наших серверах по умолчанию используется кодировка UTF-8.

В HTML для указания кодировки используется тег:

Наиболее часто встречаются типы кодировки для русского языка передаваемые в заголовке документа:

• Windows-1251 — Кириллица (Windows).
• KOI8-r — Кириллица (КОИ8-Р).
• cp866 — Кириллица (DOS).
• Windows-1252 — Западная Европа (Windows).
• Windows-1250 — Центральная Европа (Windows).
• UTF-8 — двух байтовая кодировка.

Теперь рассмотрим указание кодировки по умолчанию через .htaccess. AddDefaultCharset задает дефолтную таблицу символов (кодировку) для всех выдаваемых страниц на веб-сервере Apache. Указываем кодировку на все файлы, в которой по умолчанию получает документы браузер:

AddDefaultCharset WINDOWS-1251

При загрузке файла на сервер возможна перекодировка. Указываем, что все получаемые файлы будут иметь кодировку windows-1251, для этого напишем:

CharsetSourceEnc WINDOWS-1251

Если необходимо отменить перекодировку сервером файлов:

Управление доступом

Очень часто возникает необходимость запретить доступ к определенным файлам или папкам для определенных групп пользователей. В Web-сервере Apache есть встроенные средства для решения данной проблемы.

Для запрета или разрешения доступа ко всем файлам и папкам в текущей и во всех вложенных директориях используется директива Order, синтаксис ее очень прост:

Order [Deny,Allow] | [Allow,Deny]

# По умолчанию Deny,Allow

В зависимости от того, в каком порядке указаны директивы, меняется логика работы сервера. В случае, если Deny,Allow, то запрещается доступ со всех IP кроме оговоренных, в случае, если Allow,Deny, разрешается доступ со всех IP кроме оговоренных. Далее должны идти секции описания для доступа и запрета. Ключевое слово all означает со всех IP.

Например, мы хотим запретить (блокировать) доступ с IP 81.222.144.12 и 81.222.144.20 и разрешить всем остальным. Нам необходимо добавить в .htaccess следующий код:

Order Allow,Deny
Allow from all
Deny from 81.222.144.12 81.222.144.20

Для обратной ситуации, когда мы хотим запретить доступ со всех IP кроме 81.222.144.12 и 81.222.144.20, нам необходимо добавить в .htaccess следующий код:

Order Deny,Allow
Deny from all
Allow from 81.222.144.12 81.222.144.20

Запрет или разрешение на доступ можно указывать не только на все файлы, но так же можно указывать на отдельный файл или группы файлов. Например, мы хотим запретить доступ всех пользователей, кроме IP 81.222.144.12, к файлу passwd.html, который расположен в текущей директории:

<Files "passwd.html">
  Order Deny,Allow
  Deny from all
  Allow from 81.222.144.12
</Files>

Так же можно запретить или разрешить доступ к определенной группе файлов. Например, к файлам с расширением «.key«:

<Files ".(key)$">
  Order Deny,Allow
  Deny from all
  Allow from 81.222.144.12
</Files>

Паролирование директорий

.htaccess можно также использовать для установки пароля на доступ к определенным папкам, файлам и группам файлов. Приведем рабочий пример, а потом поясним все содержимое:

AuthName "Protected area, need authorization"
AuthType Basic
AuthUserFile /home/t/test/.authfile
require valid-user

Данный файл нужно положить в ту директорию, на которую мы хотим поставить пароль.

Директива AuthName выводит сообщение при запросе пароля, все сообщение необходимо писать в одну строчку, синтаксис директивы тривиален:

Директива AuthType выбирает тип аутентификации. Возможны следующие типы: Basic или Digest. Второй может не поддерживаться некоторыми браузерами, поэтому пользоваться им не рекомендуется.

AuthUserFile указывает имя файла с паролями для аутентификации пользователей (пароли в этом файле будут шифрованными). Путь к файлу с паролями задается относительно корня веб-сервера. Храните файл с паролями в папке, доступ к которой закрыт для пользователей. Желательно поместить этот файл вне иерархии вашего веб-сайта, например, рядом с каталогом public_html. Размещать его выше каталога сайта нецелесообразно. Это не увеличит безопасность, но потребует дополнительной настройки прав доступа в связи с изоляцией сайтов.

Если у Вас установлена операционная система семейства Windows, Вы можете подключится к серверу по SSH (инструкцию по подключению можно найти тут) и воспользоваться утилитой htpasswd.

Запустив htpasswd без параметров мы увидим:

beget@ginger ~ # htpasswd
   Usage:
   htpasswd [-cmdps] passwordfile username
   htpasswd -b[cmdps] passwordfile username password
   -c Create a new file.
 beget@ginger ~ #

Здесь не будут рассматриваться все параметры этой команды, но вы можете сами прочитать подробности, запустив htpasswd в unix shell, или ознакомившись с соответствующей страницей документации по Apache.

Итак, изначально у нас еще нет файла с паролями и нам нужно его создать:

beget@ginger ~ # htpasswd -c authfile test1
   New password:
   Re-type new password
   Adding password for user test1
 beget@ginger ~ #

После выполнения данной операции htpasswd создаст файл passwords, в котором окажется пользователь test1 и его пароль в зашифрованном виде:

beget@ginger ~ $ cat .authfile
   test1:zgco1KREjBY8M
beget@ginger ~ $

А теперь мы хотим добавить еще одного пользователя. Так как файл с паролями у нас уже есть, мы просто не будем использовать ключ ‘-c’:

beget@ginger ~ # htpasswd .authfile test2
   New password:
   Re-type new password:
   Adding password for user test2

beget@ginger ~ $ cat .authfile
   test1:zgco1KREjBY8M
   test2:eN3uA6t0kzV1c
beget@ginger ~ $

Вернемся к описанию директив паролирования директорий. Директива Require определяет пользователей, которые могут получить доступ:

Require USER_NAME | valid-user

Указывая valid-user, Вы разрешаете доступ всем пользователям, перечисленным в файле паролей.

Приведем пример для доступа определенных пользователей из файла с паролями .htpasswd:

AuthName "Protected area, need authorization"
AuthType Basic
AuthUserFile /home/t/test/.authfile
require Alexey Kondr Fenix

Также, как и с запретом доступа по IP, здесь можно использовать расширение <Files> . Ниже приведены два примера: установки пароля на один определенный файл и на группу файлов.

<Files "passwd.html">
  AuthName "Protected area, need authorization"
  AuthType Basic
  AuthUserFile /home/t/test/.authfile
  require valid-user
</Files>

<Files ".(key)$">
  AuthName "Protected area, need authorization"
  AuthType Basic
  AuthUserFile /home/t/test/.authfile
  require valid-user
</Files>

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

Указание опций PHP

Директивы для конфигурирования PHP можно размещать не только в файле php.ini, но также и в конфигурационных файлах Apache для вашего сайта – .htaccess. Это позволяет проводить тонкую настройку php для разных директорий.

Для работы с PHP в конфигурационных файлах Apache доступны 4 директивы: php_value, php_flag, php_admin_value, php_admin_flag, которые отличаются значимостью, типом устанавливаемых значений и местом применения.

Директивы php_admin_value, php_admin_flag выставляются только в файле httpd.conf, так что нам они не интересны. По сути, данные директивы переопределяют значение остальных директив.

Директива php_flag служит для установки логических значений директив в php.ini, в то время как директива php_value служит для установки строковых и числовых значений директив php.ini, т.е. любых типов значений, за исключением логических.

Синтаксис директив очень прост:

php_flag  имя директивы on | off
php_value  имя директивы VALUE

Приведем перечень наиболее часто используемых директив:

• mysql.default_host — Устанавливает имя хоста базы данных.
  Пример: php_value mysql.default_host localhost
• mysql.default_user — Устанавливает имя пользователя базы данных.
  Пример: php_value mysql.default_user alexey
• mysql.default_password — Устанавливает пароль пользователя базы данных.
  Пример: php_value mysql.default_password Hry5Gw2
• display_errors — Разрешает вывод ошибок и предупреждений в браузер.
  Пример: php_flag display_errors 0
• display_startup_errors — Включает отображение ошибок, возникающих при запуске PHP.
  Пример: php_flag display_startup_errors 0
• error_reporting — Определяет типы (уровни важности) фиксируемых ошибок.
  Пример: php_value error_reporting 32767
• auto_prepend_file — Определение файла, который будет выводится в начале каждого php-скрипта. Путь указывается от корня файловой системы сервера.
  Пример: php_value auto_prepend_file /www/server/prepend.php
• auto_append_file — Определение файла, который будет выводится в конце каждого php-скрипта.
  Пример: php_value auto_append_file /www/server/append.php
• sendmail_from — Устанавливает e-mail отправителя, который применяется при отправке почтовых сообщений с помощью PHP.
  Пример: php_value sendmail_from root@beget.com
• user_agent — Устанавливает строку User-agent, которая используется PHP при обращении к удаленным серверам.
  Пример: php_value user_agent “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)”

Например, для вывода всех сообщений об ошибках генерируемых php в .htaccess нужно прописать следующие строки:

php_flag  display_errors 1
php_flag  display_startup_errors 1
php_value  error_reporting 2047

Для запрещения выполнения php в текущей директории и во всех вложенных, необходимо в .htaccess прописать следующие строки:

Удачной работы! Если возникнут вопросы — напишите нам, пожалуйста, тикет из Панели управления аккаунта, раздел «Помощь и поддержка».

Все мы, путешествуя по просторам интернета, натыкаемся на различные ошибки при загрузке сайтов. Одна из них, кстати, достаточно часто встречается – я говорю об ошибке сервера 403 Forbidden Error. Сегодня я рассмотрю причины ее возникновения и способы устранения со стороны владельца сайта и его пользователя.

Что означает ошибка 403 и почему она появляется

Ошибка сервера 403 Forbidden означает ограничение или отсутствие доступа к материалу на странице, которую вы пытаетесь загрузить. Причин ее появления может быть несколько, и вот некоторые из них:

• Формат индексного файла неверен.
• Некорректно выставленные права на папку/файл.
• Файлы были загружены в неправильную папку.

Исправление ошибки сервера 403 Forbidden

Чтобы исправить ошибку сервера 403 Forbidden, обязательно нужен доступ к панели управления вашего хостинга. Все описанные ниже шаги применимы к любой CMS, но примеры будут показаны на основе WordPress.

Проверка индексного файла

Сначала я проверю, правильно ли назван индексный файл. Все символы в его имени должны быть в нижнем регистре. Если хотя бы один символ набран заглавной буквой, возникнет ошибка 403 Forbidden. Но это больше относится к ОС Linux, которой небезразличен регистр.

Еще не стоит забывать, что индексный файл может быть нескольких форматов, в зависимости от конфигураций сайта: index.html, index.htm, или index.php. Кроме того, он должен храниться в папке public_html вашего сайта. Файл может затеряться в другой директории только в том случае, если вы переносили свой сайт.

Любое изменение в папке или файле фиксируется. Чтобы узнать, не стала ли ошибка итогом деятельности злоумышленников, просто проверьте графу «Дата изменения».

Настройка прав доступа

Ошибка 403 Forbidden появляется еще тогда, когда для папки, в которой расположен искомый файл, неправильно установлены права доступа. На все директории должны быть установлены права на владельца. Но есть другие две категории:

• группы пользователей, в числе которых есть и владелец;
• остальные, которые заходят на ваш сайт.

На директории можно устанавливать право на чтение, запись и исполнение.

Так, по умолчанию на все папки должно быть право исполнения для владельца. Изменить их можно через панель управления TimeWeb. Для начала я зайду в раздел «Файловый менеджер», перейду к нужной папке и выделю ее. Далее жму на пункт меню «Файл», «Права доступа».  

Откроется новое окно, где я могу отрегулировать права как для владельца, так и для всех остальных.

Отключение плагинов WordPress

Если даже после всех вышеперечисленных действий ошибка не исчезла, вполне допустимо, что влияние на работу сайта оказано со стороны некоторых плагинов WordPress. Быть может они повреждены или несовместимы с конфигурациями вашего сайта.

Для решения подобной проблемы необходимо просто отключить их. Но сначала надо найти папку с плагинами. Открываю папку своего сайта, перехожу в раздел «wp-content» и нахожу в нем директорию «plugins». Переименовываю папку – выделяю ее, жму на меню «Файл» и выбираю соответствующий пункт. Название можно дать вот такое: «plugins-disable». Данное действие отключит все установленные плагины.

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

Но что делать, если у вас плагин не один, а какой из них влияет на работу сайта – неизвестно? Тогда можно вернуть все как было и провести подобные действия с папками для определенных плагинов. Таким образом, они будут отключаться по отдельности. И при этом каждый раз надо перезагружать страницу и смотреть, как работает сайт. Как только «виновник торжества» найден, следует переустановить его, удалить или найти альтернативу.

Как решить проблему, если вы – пользователь

Выше я рассмотрела способы устранения ошибки 403 Forbidden для владельцев сайта. Теперь же разберу методы исправления в случаях с пользователем.

• Сначала надо убедиться, что проблема заключается именно в вашем устройстве. Внимательно проверьте, правильно ли вы ввели URL сайта. Может, в нем есть лишние символы. Или, наоборот, какие-то символы отсутствуют.
• Попробуйте загрузить страницу с другого устройства. Если на нем все будет нормально, значит, проблема кроется именно в используемом вами девайсе. Если нет – надо перейти к последнему шагу.
• Еще хороший вариант – немного подождать и обновить страницу. Делается это либо кликом по иконке возле адресной строки браузера, либо нажатием на комбинацию Ctrl + F5. Можно и без Ctrl, на ваше усмотрение.
• Если ничего из вышеперечисленного не помогло, надо очистить кэш и cookies. Провести такую процедуру можно через настройки браузера. Для этого необходимо открыть историю просмотров, чтобы через нее перейти к инструменту очистки. Эту же утилиту часто можно найти в настройках, в разделе «Конфиденциальность и безопасность». В новом окне нужно отметить пункты с кэшем и cookies и нажать на кнопку для старта очистки.

• Ошибка 403 Forbidden возникает и тогда, когда пользователь пытается открыть страницу, для доступа к которой сначала надо осуществить вход в систему. Если у вас есть профиль, просто войдите в него и попробуйте вновь загрузить нужную страницу.
• Если вы заходите со смартфона, попробуйте отключить функцию экономии трафика в браузере. Она находится в настройках, в мобильном Google Chrome под нее отведен отдельный раздел. 
• Последний шаг – подождать. Когда ни один способ не помогает, значит, неполадки возникли именно на сайте. Возможно, его владелец уже ищет способы решения проблемы и приступает к их исполнению, но это может занять какое-то время. Пользователям остается только дождаться, когда все работы будут завершены.

Еще одна допустимая причина появления ошибки сервера 403 – доступ к сайту запрещен для определенного региона или страны, в которой вы находитесь. Бывает и такое, что сайт доступен для использования только в одной стране. Если вы используете VPN, попробуйте отключить его и перезагрузите страницу. Вдруг получится все исправить. 

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

Ошибка 403 (error 403 Forbidden) — это ответ сервера, который отправляется, когда доступ к странице запрещен или ограничен по ряду причин. 

Текстовое описание ошибки может варьироваться. Вот некоторые вариации:

• 403 Forbidden.
• Access denied.
• «В доступе отказано».
• Forbidden.
• You don’t have permission to access.
• Запрещено 403. 

Перепутать ошибку с другими сложно, так как на странице обязательно будет указан код ошибки 403.

Как исправить ошибку 403

Почему возникает ошибка? Самый частый вариант — у пользователя недостаточно прав для просмотра страницы или контента на ней. Запрет с кодом 403 может установить администратор сети, администратор сервера, провайдер или разработчик.

Чаще всего причины появления ошибки связаны с проблемами на стороне сайта. Ниже отметим самые распространенные причины ошибки и расскажем, как исправить ситуацию.

Не успел обновиться кэш DNS серверов

Эта проблема часто возникает при переносе домена между разными регистраторами, а также при попытках перенести домен на разные аккаунты у одного регистратора. 

Решение: подождать. Обновление DNS записей, как правило, может занимать от 4 до 24 часов.

Ошибку вызывает плагин

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

Решение: найти проблемное расширение и отключить его.

Доступ к сайтам ограничен для пользователей из определенного местоположения

Одна из самых актуальных причин ошибки 403 в последние месяцы у россиян. Дело в том, что многие английские, украинские и европейские сайты начали блокировать доступ по географическому признаку. В итоге при попытке открыть любую страницу такого сайта вы увидите ошибку.

Решение: воспользоваться VPN-сервисом. 

Некорректный файл индекса сайта

Одна из самых частых причин ошибки на всех страницах сайта. Суть в том, что индексный файл располагается в некорректной директории, вовсе отсутствует или имеет неправильный формат. 

Решение: проверить индексный файл своего сайта. Для этого откройте файловый менеджер используемого хостинга и найдите файл со словом index. 

Если вы пользуетесь услугами REG.RU, там также есть встроенный файловый менеджер. Чтобы получить к нему доступ, выполните следующие действия:

1. В левом навигационном меню выберите пункт «Сайты».
2. Выберите проблемный домен.
3. Кликните по кнопке «Менеджер файлов» (в новой версии «Файлы сайта»).
4. Найдите индексный файл в корневой директории сайта.

Обязательно проверьте необходимый формат индексного файла: далеко не всегда он должен иметь расширение .HTML.

В зависимости от используемой системы управления контентом и конфигурации сайта индексный формат файла может отличаться: возможные варианты расширения — HTML, PHP, HTM.

В разных панелях управления проверка индексного файла происходит по-разному. Посмотрим, как проверить индексный файл в ISPmanager — однойиз самых популярных панелей управления сегодня.

1. В навигационном меню слева нажимаем кнопку «Сайты».
2. Выбираем проблемный домен, нажимаем кнопку «Изменить».
3. В самом низу находим строку «Индексная страница»:

Приостановлено обслуживание сайта на конкретном хостинге

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

Решение: оплатить услуги хостинга.

Некорректное месторасположение файлов сайта

Частая проблема, возникающая при ручном переносе файлов сайта. Здесь правило простое: файлы сайта располагаются в корневой директории.

Решение: убедиться, что папка с файлами сайта находится в правильной папке. Корневая папка сайта по управлением WordPress на хостинге Beget может выглядеть так:

Указаны некорректные права на файл или папку 

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

Для задания самих прав используются трехзначные коды:

• Для папок — код 755 или код 750;
• Для файлов — код 644 или код 640.

Вы можете установить любой из этих вариантов.

У разных CMS могут быть свои коды для указания прав папок и файлов. Например, в WordPress на системный файл wp-config.php должны быть настроены права с кодом 440 (или с кодом 400).

Решение: проанализировать права всех папок и изменить их при необходимости. Проверьте, какие файлы и папки загружаются при открытии страницы с 403-м ответом. Чтобы уточнить этот момент, вы можете обратиться в техподдержку хостинга.  

Некорректные указания в конфигурационном файле htaccess

.htaccess — это файл конфигурации для использования на веб-серверах с программным обеспечением Apache Web Server. Когда .htaccess помещается в каталог (который, в свою очередь, загружается через веб-сервер Apache), он обнаруживается и выполняется программным обеспечением веб-сервера Apache.

Рассмотрим пример директивы, которая запрещает доступ к сайту всем пользователям, кроме одного IP-адреса:

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

Решение: найти файл .htaccess в папке сайта и проанализировать команды, которые были прописаны недавно.

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

Особое внимание обратите на команды со словами deny, redirect, require: 

Удалите все соответствующие строки (со словами deny, redirect, require) и сохраните файл. Отключите кэширование данных на сайте и проверьте доступность страницы, которая отдавала 403-й код. Если все работает, значит причина была именно в .htaccess. Снова включите кэширование данных. 

Если страница все равно не открывается, измените название файла htaccess на old_htaccess. Убедитесь, что кэширование данных на сайте отключено и снова откройте проблемную страницу. Если страница по-прежнему отдает код 403, дело точно не в htaccess и проверять нужно другие причины, которые мы описали выше.

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

Иные причины 403 ошибки

• Работодатель ограничивает доступ ко всем публичным сайтам, кроме тех, которые нужны для работы.
• Доступ к сайту временно ограничен вебмастером по определенному признаку, например, по используемому браузеру.
• Допущена опечатка в URL страницы (при ручном вводе).
• Пользователь пытается открыть страницу сайта, предназначенную для служебного использования.
• Пользователь пытается открыть страницу сайта, предназначенную для использования только зарегистрированными пользователями.
• Пользователь был заблокирован по какому-либо параметру, например по IP-адресу (за нарушение правил пользования сайтом).
• Доступ к сайту временно приостановлен для всех пользователей, так как проводится его техническое обслуживание.

Резюме

Используйте чек-лист, который поможет исправить ошибку 403 вебмастеру и пользователю.

Вебмастеру

1. Убедитесь, что указан корректный адрес страницы.
2. Проверьте директивы в системном файле htaccess.
3. Убедитесь, что все файлы сайта находятся в корневом каталоге.
4. Проверьте наличие всех необходимых файлов, которые загружаются при обращении к проблемной странице.
5. Свяжитесь с хостингом и уточните, имеются ли какие-либо ограничения, наложенные на ваш сайт или домен.
6. Убедитесь, что выставлены корректные права доступа на папки и файлы.

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

Пользователю

У пользователя возможности исправить ошибку гораздо меньше, так как причина, чаще всего, находится не на его стороне. Что вы можете сделать:

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

Часто адрес страницы меняется дважды после публикации и поисковые системы просто не успевают обработать новую версию адреса. Следует подождать хотя бы один день. Страница с некорректным URL покинет индекс, исчезнет из результатов поиска, а на ее место придет страница с правильным адресом.

#1

 

Отправлено 25 мая 2021 — 22:48

<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx-reuseport/1.13.4</center>
</body>
</html>

CMD:http(playerid, params[])
{
    new string[6];
    HTTP(playerid, HTTP_GET, "a95602jt.beget.tech/mailer/mailer.php?name=Merson_Darklight&email=*емейл нидам*&code=987654&key=*ключ доступа тоже нидам*", "", "MyHttpResponse");
    return SendClientMessage(playerid, -1, "Запрос отправлен.");
}
forward MyHttpResponse(index, response_code, data[]);
public  MyHttpResponse(index, response_code, data[])
{
    new string[144];
    if (response_code == 200)
        format(string, sizeof(string), "Ответ сайта: %s", data);
    else
    {
        format(string, sizeof(string), "Неудача - запрос завершился с кодом %d", response_code);
        print(data);
    }
    return SendClientMessage(index, -1, string);
}

0

#2

Отправлено 25 мая 2021 — 23:05

0

#3

Отправлено 25 мая 2021 — 23:51

0

#4

Отправлено 26 мая 2021 — 00:02

0

#5

Отправлено 26 мая 2021 — 00:10

0

#6

Отправлено 26 мая 2021 — 05:39

stock StringURLEncode(string[], size = sizeof(string))
{
    for(new i = 0, l = strlen(string), hex[8]; i < l; i++)
    {
        switch(string[i])
        {
            case '!', '(', ')', 
                ''', '*',
                '0' .. '9',
                'A' .. 'Z',
                'a' .. 'z':
            {
                continue;
            }

            case ' ':
            {
                string[i] = '+';
                continue;
            }
        }

        if(i+3 >= size)
        {
            string[i] = EOS;
            return 0;
        }

        if(l+3 >= size)
            string[size-3] = EOS;

        format(hex, sizeof(hex), "%02h", string[i]);

        string[i] = '%';

        strins(string, hex, i + 1, size);

        l += 2;
        i += 2;

        if (l > size - 1)
            l = size - 1;
    }
    return 1;
}

1

#7

Отправлено 26 мая 2021 — 14:50

CMD:http(playerid, params[])
{
    new string[120];
    format(string, sizeof(string), "a95602jt.beget.tech/mailer/mailer.php?name=%s&email=%s&code=%d%d%d%d%d%d", pInfo[playerid][pName], params[0], random(9), random(9), random(9), random(9), random(9), random(9));
    //print(string);
    HTTP(playerid, HTTP_GET, StringURLEncode(string), "", "MyHttpResponse");
    return SendClientMessage(playerid, -1, "Запрос отправлен.");
}

StringURLEncode(string)

0

#8

Отправлено 26 мая 2021 — 19:30

0

#9

Отправлено 26 мая 2021 — 22:43

a95602jt%2Ebeget%2Etech%2Fmailer%2Fmailer%2Ephp%3Fname%3DMerson%5FDarklight%26email%3D%26code%3D766484%
26key%3Db4a7aa2883b87b9661b8c2a578a73de5

CMD:http(playerid, params[])
{
    new string[300];
    format(string, sizeof(string), "a95602jt.beget.tech/mailer/mailer.php?name=%s&email=%s&code=%d%d%d%d%d%d&key=b4a7aa2883b87b9661b8c2a578a73de5"
, pInfo[playerid][pName], params[0], random(9), random(9), random(9), random(9), random(9), random(9));
    StringURLEncode(string);
    print(string);
    HTTP(playerid, HTTP_GET, string, "", "MyHttpResponse");
    return SendClientMessage(playerid, -1, "Запрос отправлен.");
}
forward MyHttpResponse(index, response_code, data[]);
public  MyHttpResponse(index, response_code, data[])
{
    new string[144];

    // Если HTTP-запрос совершился успешно (код 200), выведем ответ сайта, иначе - сообщим код ошибки.
    if (response_code == 200)
        format(string, sizeof(string), "Ответ сайта: %s", data);
    else
    {
        format(string, sizeof(string), "Неудача - запрос завершился с кодом %d", response_code);
        print(data);
    }

    // В параметре index содержится ID игрока, который был передан 1-м параметром в вызове HTTP().
    return SendClientMessage(index, -1, string);
}

0

#10

Отправлено 27 мая 2021 — 06:03

0

Да, бегет, бесплатнй хостинг…

В техподдержку писал по4ти меся назад, полу4ил отписку:

«Искандер Марсилович

Служба технической поддержки

27.03.18

Техническая поддержка на бесплатном хостинге не оказывается. Поддержка не предоставляется по любым вопросам

относительно работы ваших сайтов.

Поддержка предоставляется только по вопросам оплаты, регистрации и продлении доменных имен, а также DNS.

Если у вас, что либо не получается в панели управления и ошибки связаны с этим рекомендуем ознакомиться с :

инструкцией по работе с панель управления — https://beget.com/ru/manual

вопросами и ответами на нашем сайте — https://beget.com/ru/faq

полезными статьями — https://beget.com/ru/articles

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

Сервис предоставляется Пользователю по принципу «как есть» и мы не гарантируем его бесперебойную работу.

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

“Соглашении о предоставлении сервиса” — https://beget.com/ru/rulesfree

При блокировки аккаунта или сайта в связи с нарушением правил сервиса — разблокировка аккаунта или сайта на бесплатном хостинге не возможна.

Вы можете перейти на платный хостинг для получения технической поддержки и услуг хостинга в полном объеме и стандартами поддержки и оказания платных услуг хостинга — https://cp.beget.com/switchtopaid

Обращаем внимание, что обратный переход на бесплатный хостинг не представляется возможным.»

Неужели бегет таким хитрим образом создает проблему для части браузеров, чтобы загнать клиентов на платный хостинг?

Как такое технически возможно, можно ли обойти проблему?

I have developed a JavaScript code that sends periodically, every 500 msec, a GET request to an HTTP server, which answers to this request with text data in JSN format.

function get(theUrl, success, failure, commData)
{
    commData = commData || {};
    return fetch(theUrl)
    .then(function(res)
    {
        if (!res.ok)
        throw Error(res.statusText);
        return res;
    })
    .then(function(res)
    {
        return res.text();
    })
    .then(function(html)
    {
        success(html, commData);
    })
    .catch(function(error)
    {
        failure(commData);
    });
}

This javascript code is part of the resources (js, css, images) that are downloaded along with the index.html from the HTTP server.

The client receives answer from the server without any problem for some minutes. Suddenly, around 15 minutes after the download of the index.html, the browser inspector shows that the client starts receiving systematically error 403 («forbidden») to the GET request. This happens with any browser (at least with Firefox, Chrome and IE/Edge). When the 403 error occurs, the failure() function of the above code sample is triggered.

I have monitored the connection with Wireshark, and I could see that, in spite of the 403 error, actually the HTTP server is still receiving the request and is sending the (correct) answer.

It looks like that in the browser there is some timer that is started when loading the home page (index.html), and which expires after some minutes, causing the fetch() API to fail with error 403.

I need that the periodical GET can works indefinitely, without limit of time, because its purpose is to monitor the state and retrieve important diagnostic data from an embedded system.
How can I solve it?

EDIT:
First of all; I have to correct the text and the title of this post, because the «forbidden» error is not 503, but 403. I apologize for the mistake.

Secondly, I am adding some useful information. The webserver is running on RTOS in a Concerto F28M36x processor. In order to make a simulation test and to debug more easily, I adapted the code of webserver in order to have it running on a Window machine, using the MSDN C++ HTTP API (https://learn.microsoft.com/en-us/windows/win32/http/http-server-api-overview). In this scenario, the HTTP server is running on the same computer of the client (localhost). Nevertheless, the behavior (with error 403) is exactly the same, as when the webserver is running in the embedded system. Here is what is shown by the browser inspector, when the GET request is successful (result=200):

GET http://localhost/readResults.cgi
Status 200 OK
Version HTTP/1.1
Transferred 308 B (174 B size)
Referrer Policy no-referrer-when-downgrade

Response header: (157 B)
Content-Length 174
Content-Type text/plain
Date Tue, 06 Apr 2021 11:00:39 GMT
Server Microsoft-HTTPAPI/2.0
    
Request headers (421 B):
Accept */*
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
cache-control no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0
Connection keep-alive
expires Tue, 01 Jan 1980 1:00:00 GMT
Host localhost
pragma no-cache
Referer http://localhost/
Sec-GPC 1
User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

And this is shown by the browser inspector when the result is 403:

GET http://localhost/readResults.cgi
Status 403 Forbidden
VersionHTTP/1.1
Transferred 4.11 KB (3.95 KB size)
Referrer Policy no-referrer-when-downgrade

Response header: (157 B)
Cache-Control no-cache
Connection close
Content-Length 4047
Content-Type text/html; charset=UTF-8
Proxy-Connection close

Request headers (421 B):
Accept */*
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
cache-control no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0
Connection keep-alive
expires Tue, 01 Jan 1980 1:00:00 GMT
Host    localhost
pragma  no-cache
Referer http://localhost/
Sec-GPC 1
User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

As one can see, with respect to the «good» case, in the «bad» case the following additional fields are present in the response header:

Connection: close
Proxy-Connection: close

Edit — since I am not receiving any answer, could somebody please suggest me a different forum where I can post this question?

Edit — just a gentle reminder. Any suggestion?

I have developed a JavaScript code that sends periodically, every 500 msec, a GET request to an HTTP server, which answers to this request with text data in JSN format.

function get(theUrl, success, failure, commData)
{
    commData = commData || {};
    return fetch(theUrl)
    .then(function(res)
    {
        if (!res.ok)
        throw Error(res.statusText);
        return res;
    })
    .then(function(res)
    {
        return res.text();
    })
    .then(function(html)
    {
        success(html, commData);
    })
    .catch(function(error)
    {
        failure(commData);
    });
}

This javascript code is part of the resources (js, css, images) that are downloaded along with the index.html from the HTTP server.

The client receives answer from the server without any problem for some minutes. Suddenly, around 15 minutes after the download of the index.html, the browser inspector shows that the client starts receiving systematically error 403 («forbidden») to the GET request. This happens with any browser (at least with Firefox, Chrome and IE/Edge). When the 403 error occurs, the failure() function of the above code sample is triggered.

I have monitored the connection with Wireshark, and I could see that, in spite of the 403 error, actually the HTTP server is still receiving the request and is sending the (correct) answer.

It looks like that in the browser there is some timer that is started when loading the home page (index.html), and which expires after some minutes, causing the fetch() API to fail with error 403.

I need that the periodical GET can works indefinitely, without limit of time, because its purpose is to monitor the state and retrieve important diagnostic data from an embedded system.
How can I solve it?

EDIT:
First of all; I have to correct the text and the title of this post, because the «forbidden» error is not 503, but 403. I apologize for the mistake.

Secondly, I am adding some useful information. The webserver is running on RTOS in a Concerto F28M36x processor. In order to make a simulation test and to debug more easily, I adapted the code of webserver in order to have it running on a Window machine, using the MSDN C++ HTTP API (https://learn.microsoft.com/en-us/windows/win32/http/http-server-api-overview). In this scenario, the HTTP server is running on the same computer of the client (localhost). Nevertheless, the behavior (with error 403) is exactly the same, as when the webserver is running in the embedded system. Here is what is shown by the browser inspector, when the GET request is successful (result=200):

GET http://localhost/readResults.cgi
Status 200 OK
Version HTTP/1.1
Transferred 308 B (174 B size)
Referrer Policy no-referrer-when-downgrade

Response header: (157 B)
Content-Length 174
Content-Type text/plain
Date Tue, 06 Apr 2021 11:00:39 GMT
Server Microsoft-HTTPAPI/2.0
    
Request headers (421 B):
Accept */*
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
cache-control no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0
Connection keep-alive
expires Tue, 01 Jan 1980 1:00:00 GMT
Host localhost
pragma no-cache
Referer http://localhost/
Sec-GPC 1
User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

And this is shown by the browser inspector when the result is 403:

GET http://localhost/readResults.cgi
Status 403 Forbidden
VersionHTTP/1.1
Transferred 4.11 KB (3.95 KB size)
Referrer Policy no-referrer-when-downgrade

Response header: (157 B)
Cache-Control no-cache
Connection close
Content-Length 4047
Content-Type text/html; charset=UTF-8
Proxy-Connection close

Request headers (421 B):
Accept */*
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
cache-control no-cache, must-revalidate, post-check=0, pre-check=0, max-age=0
Connection keep-alive
expires Tue, 01 Jan 1980 1:00:00 GMT
Host    localhost
pragma  no-cache
Referer http://localhost/
Sec-GPC 1
User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101 Firefox/84.0

As one can see, with respect to the «good» case, in the «bad» case the following additional fields are present in the response header:

Connection: close
Proxy-Connection: close

Edit — since I am not receiving any answer, could somebody please suggest me a different forum where I can post this question?

Edit — just a gentle reminder. Any suggestion?