403 forbidden что за ошибка: Ошибка 403 forbidden — что значит доступ запрещён, как исправить

Posted on by alexxlab

Что такое ошибка 403 forbidden и как ее исправить?

                               

Всем привет друзья. В сегодняшней статье, я хочу рассказать вам об ошибке под названием 403 forbidden и дать точное пояснение, отчего эта ошибка может возникать. Более чем уверен, что многие из вас, уже встречались с таким явлением при работе в сети Интернет или же простого просмотра страниц сайтов. Естественно, появление такого рода страниц сильно раздражает и вряд ли вызовет доверие к вашему сайту в целом. Давайте более детально ознакомимся с самим термином, и я объясню вам, основные причины по которым возникает ошибка 403.
Чтобы сразу стало понятно, я объясню все на простом примере. Давайте перейдем по вот такому адресу на моем блоге:

[ads-pc-1]
[ads-mob-1]

www.seofive.ru/wp-content/uploads

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

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

1) В корне вашего сайта присутствует неправильный файл главной страницы сайта. Обычно (в нормальном режиме работы) это файлы под такими названиями:

index.php, index.html, index.htm, index.shtml

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

Поэтому внимательно обратите внимание на то расширение, которое необходимо вашему сайту и посмотрите, чтобы адрес главной страницы был прописан в нижнем регистре. Чтобы не было, к примеру, так – Index.php, или Index.html

Бывают случаи, когда главная страница сайта названа не стандартно, к примеру, вместо index.php она называется home.php. В таком случае необходимо переименовать страницу к стандартам, описанным выше или же создать надпись в файле .htaccess:

DirectoryIndex home.php

Таким образом, указав серверу нестандартную главную страницу вашего сайта.

2) Вторая причина, по которой возникает ошибка 403 forbidden, это некорректные права на запрашиваемую страницу пользователем.

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

Но иногда и для обычных пользователей необходимо выставить точно такие же права. Здесь мы поставим права – 755, чтобы и Администратор сайта и обычные пользователи имели одинаковые права.

3) Страница, запрашиваемая пользователем, находится не в корректной папке на хостинге.

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

4) Установка ограничения к сайту или отдельным папкам/файлам через файл .htaccess. Такое иногда бывает, когда владелец сайта или его Администратор преднамеренно закрывают доступ к определенной информации. Решение очень простое – убираем эти строки или комментируем их, простановкой символа # перед такими строками.

5) Ошибка 403 может возникать из-за того, что владелец сайта закрыл доступ к ресурсу для определенных IP-адресов. Как исправить проблему? Попробовать зайти на сайт с другого IP-адреса.

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

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

Ну, все друзья, всем пока! Хороших праздников!

P. S. Про конкурсы, я не забыл, и в следующей статье, оглашу имена победителей. Ждите!

[ads-pc-2]
[ads-mob-2]
  1. 5
  2. 4
  3. 3
  4. 2
  5. 1

(36 голосов, в среднем: 3.8 из 5)

Написать комментарий

Как исправить ошибку 403 «Запрещено в Cloudflare»? Лучшее руководство

by Айшвар Баббер

В этом посте мы расскажем, как исправить ошибку 403 Forbidden On Cloudflare?

Запрещенная ошибка Cloudflare 403 довольно утомительна. Это может быть следствием системных модификаций или обновлений, сделанных вашим хостинг-провайдером, или ошибок при настройке с вашей стороны.

Я рассмотрю возможные исправления для запрещенных ошибок 403 на вашем сайте.

Содержание

  • Что такое ошибка 403 Forbidden Cloudflare-Nginx?
  • Как исправить ошибку 403 «Запрещено в Cloudflare»? Причины ошибки?
  • Ошибка Cloudflare 403 Forbidden: как это исправить?
    • 1. Пустой каталог веб-сайтов
    • 2. Нет индексной страницы
    • 3. Разрешения и право собственности
  • Вывод: как исправить ошибку 403 Forbidden on Cloudflare?

Что такое ошибка 403 Forbidden Cloudflare-Nginx?

Ошибка 403 Cloudflare возникает, когда клиент отправляет запрос, который источник не может одобрить или обработать. Код состояния HTTP-запрещенной ошибки указывает на отказ в разрешении.

Давайте рассмотрим источники проблем Cloudflare и способы их решения на вашем веб-сайте.

Как исправить ошибку 403 «Запрещено в Cloudflare»? Причины ошибки?

Как правило, Cloudflare будет предоставлять только ответы 4xx, в противном случае доступ к Cloudflare будет запрещен по причинам, перечисленным ниже.

  • Брандмауэр веб-приложений Cloudflare (WAF) потерпит неудачу, если ваш запрос нарушит какое-либо из его правил.
  • Запрос будет отклонен, если он нарушает правило WAF, включенное для зоны, к которой вы пытались получить доступ.
  • Домен или субдомен с недействительным SSL сертификат не может быть достигнуто через SSL.

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

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

Основные причины, по которым вы можете увидеть код состояния HTTP

  • Каталог сайта пуст
  • Вы установили правила с ошибками разрешения/владения
  • Индексной страницы нет

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

Ошибка Cloudflare 403 Forbidden: как это исправить?
  • Каталог веб-сайта, который пуст
  • Индексной страницы нет
  • Право собственности и разрешения

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

1. Пустой каталог веб-сайтов

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

  1. Плеск-сервер: /var/www/vhosts/website.com/httpdocs/
  • После подключения к FTP-пользователю перейдите в каталог httpdocs.
  • Вместо Website.com используйте свое фактическое доменное имя.

2. Сервер cPanel:/главная/веб-сайт/public_html/

  • Перейдите в каталог public_html после подключения к FTP.
  • Ваше имя пользователя cPanel должно быть заменено на веб-сайт.

Примечание: Если его нет на вашем сайте, создайте его немедленно

2. Нет индексной страницы

Главная страница вашего веб-сайта должна называться index.php или index.html, а имена файлов вводятся с учетом регистра. Вы можете решить эту проблему, загрузив индексную страницу в общедоступный каталог html или httpdocs.

Если у вас уже есть домашняя страница с другим именем, например log. html, рассмотрите следующие варианты.

  • Ваша домашняя страница должна быть переименована из log.html в index.php или index.html.
  • Индексная страница должна быть перенаправлена ​​на желаемую домашнюю страницу.
  • Сделайте файл .htaccess страницей по умолчанию

3. Разрешения и право собственности

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

Вот правильная настройка разрешений:

  • Папок: 755
  • Статическое содержимое: 644
  • Динамический контент: 700

Альтернативы Forbidden 403 Cloudflare Error

  • Временное сообщение может появиться из-за перехода с бесплатной на профессиональную подписку. Изменение сертификата бесплатной учетной записи на профессиональную учетную запись может привести к ошибке Cloudflare 403.
  • Возможно, кэш DNS клиента указывает на исходный сервер. Смените браузер или используйте приватный режим просмотра.
  • Сайт может быть отключен от проверки целостности браузера.
  • Определите, настроен ли блок страны на исходном сервере, если ошибка возникает только в определенных странах.
  • Если Cloudflare вызывает проблему, приостановите ее, пока вы не сможете ее исправить. Опцию «Приостановить Cloudflare» можно найти в «Расширенном меню» на панели инструментов Cloudflare.
  • Вы также можете обратиться к сообществу Cloudflare за помощью с ошибками 4xx; там можно найти советы по их устранению.

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

Быстрые ссылки:

  • Как написать увлекательный контент на «скучную» тему?
  • Как начать блог: Шаг № 1 Выберите доменное имя
  • Как создать онлайн-курс за 15 минут с Everlesson

Вывод: как исправить ошибку 403 Forbidden on Cloudflare?

4xx Cloudflare — это сообщение, с которым пользователи могут столкнуться по многим причинам, и иногда оно может раздражать. Я изложил причины проблемы и рекомендуемые решения.

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

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

Айшвар Баббер

Айшвар Баббер — страстный блогер и специалист по цифровому маркетингу. Он любит говорить и вести блог о новейших технологиях и гаджетах, что мотивирует его работать ГизмоБейс. В настоящее время он практикует свои знания в области цифрового маркетинга, SEO и SMO ​​в качестве штатного маркетолога в различных проектах. Он является активным инвестором в AffiliateBay.

Устранение ошибок HTTP 403 от шлюза API

При вызове API шлюза API Amazon я получаю сообщение об ошибке 403. Как устранить ошибки 403 от API Gateway?

Краткое описание

Код ответа HTTP 403 означает, что клиенту запрещен доступ к действительному URL-адресу. Сервер понимает запрос, но не может его выполнить из-за проблем на стороне клиента.

API шлюза API могут возвращать ответы 403 по любой из следующих причин:

Issue Response header Error message Root cause
Access denied «x-amzn-errortype» = «AccessDeniedException» «Пользователь не авторизован для доступа к этому ресурсу с явным запретом» Вызывающий объект не авторизован для доступа к API, который использует авторизатор API Gateway Lambda.
Доступ запрещен «x-amzn-errortype» = «AccessDeniedException» «Пользователь: не авторизован для выполнения: execute-api: Вызвать ресурс: с явным отказом» Вызывающий объект не авторизован для доступа к API, который использует авторизацию AWS Identity and Access Management (IAM). Или у API есть прикрепленная политика ресурсов, которая явно запрещает доступ к вызывающей стороне. Дополнительные сведения см. в разделе Проверка подлинности IAM и политика ресурсов.
Доступ запрещен «x-amzn-errortype» = «AccessDeniedException» «Пользователь: анонимный не авторизован для выполнения: execute-api:Вызов на ресурсе:» вызывающий объект не авторизован для доступа к API, который использует авторизацию IAM. Или у API есть прикрепленная политика ресурсов, которая явно не разрешает вызывающей стороне вызывать API. Дополнительные сведения см. в разделе Проверка подлинности IAM и политика ресурсов.
Доступ запрещен «x-amzn-errortype» = «AccessDeniedException» «Маркер безопасности, включенный в запрос, недействителен.» Вызывающий использовал недопустимые ключи IAM для доступа к API, использующему авторизацию IAM.
Отсутствует токен аутентификации «x-amzn-errortype» = «MissingAuthenticationTokenException» «Отсутствует токен аутентификации» Токен аутентификации не найден в запросе.
Срок действия маркера аутентификации истек «x-amzn-errortype» = «InvalidSignatureException» «Срок действия подписи истек» Срок действия маркера аутентификации в запросе истек.
Ключ API недействителен «x-amzn-errortype» = «ForbiddenException» «Указан неверный идентификатор ключа API» Вызывающий использовал ключ API, который недействителен для метода, требующего API ключ.
Подпись недействительна «x-amzn-errortype» = «InvalidSignatureException» «Рассчитанная нами подпись запроса не соответствует предоставленной вами подписи. Проверьте свой секретный ключ доступа AWS и метод подписи». Подпись в запросе не совпадает с подписью на сервере при доступе к API, использующему авторизацию IAM.
AWS WAF отфильтрован «x-amzn-errortype» = «ForbiddenException» «Forbidden» Запрос блокируется фильтрацией брандмауэра веб-приложения, когда AWS WAF активирован в API.
Путь к ресурсу не существует «x-amzn-errortype» = «MissingAuthenticationTokenException» «Отсутствует токен аутентификации» Запрос без заголовка «Авторизация» отправляется на путь ресурса API, который не т существует. Дополнительные сведения см. в разделе Как устранить ошибки 403 «Отсутствует токен аутентификации» в конечной точке REST API шлюза API?
Путь к ресурсу не существует «x-amzn-errortype» = «IncompleteSignatureException» «Заголовок авторизации требует параметра «Учетные данные». Заголовок авторизации требует параметра «Подпись». Заголовок авторизации требует параметра «SignedHeaders». Заголовок авторизации требует наличия заголовка «X-Amz-Date» или «Дата». Авторизация = allow» Запрос с заголовком «Авторизация» отправлен на несуществующий путь ресурса API.
Неправильный вызов частного API с использованием общедоступных DNS-имен «x-amzn-errortype» = «ForbiddenException» «Запрещено» Вызов частного API из виртуального частного облака Amazon (Amazon VPC) с неправильным использованием общедоступных DNS-имен. Например: в запросе отсутствует заголовок «Host» или «x-apigw-api-id» . Дополнительные сведения см. в разделе Вызов вашего частного API с использованием общедоступных имен узлов DNS для конкретных конечных точек.
Вызов REST API с именем пользовательского домена с использованием конечной точки по умолчанию execute-api «x-amzn-errortype» = «ForbiddenException» «Запрещено» Вызывающий использует конечную точку execute-api по умолчанию для вызова REST API после деактивации конечной точки по умолчанию. Дополнительные сведения см. в разделе Отключение конечной точки по умолчанию для REST API
Вызов личного доменного имени шлюза API, для которого требуется взаимная безопасность транспортного уровня (TLS) с использованием недействительного сертификата клиента. «x-amzn-errortype» = «ForbiddenException» «Forbidden» Сертификат клиента, представленный в запросе API, не выдан хранилищем доверенных сертификатов пользовательского доменного имени или недействителен. Дополнительные сведения см. в разделе Как устранить ошибки HTTP 403 Forbidden из личного доменного имени шлюза API, требующего взаимного TLS?
Вызов пользовательского доменного имени без сопоставления базового пути «x-amzn-errortype» = «ForbiddenException» «Запрещено» Вызывающий объект вызывает пользовательский домен без сопоставления базового пути с API. Дополнительные сведения см. в разделе Настройка пользовательских доменных имен для REST API.
Вызов API с включенным личным доменом, когда URL-адрес домена включает этап «x-amzn-errortype» = «MissingAuthenticationTokenException» «Отсутствует токен аутентификации» Сопоставление API указывает API, этап и, возможно, путь для использования для сопоставления. Поэтому, когда этап API сопоставляется с личным доменом, вам больше не нужно включать этап в URL-адрес. Дополнительные сведения см. в разделе Работа с сопоставлениями API для REST API.
URL-адрес этапа в запросе недействителен «x-amzn-errortype» = «ForbiddenException» «Forbidden» URL-адрес запроса вызывающей стороны включает несуществующий этап. Убедитесь, что этап существует и правильность написания URL-адреса запроса. Дополнительные сведения см. в разделе Вызов REST API в Amazon API Gateway.

Решение

Рассмотрите источник ошибки

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

  • Если об ошибке сообщается в веб-браузере, то эта ошибка может быть вызвана неправильной настройкой прокси-сервера. Прокси-сервер возвращает ошибку 403, если HTTP-доступ запрещен.
  • Если перед API есть другой сервис AWS, то этот сервис может отклонить запрос с ошибкой 403 в ответе. Например: Amazon CloudFront.

Определите причину ошибки

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

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

1.    Создайте новое сопоставление API для вашего личного доменного имени, которое вызывает REST API только для тестирования.

2.    Определите причину ошибок, просмотрев журналы выполнения REST API в CloudWatch.

3.    После того, как ошибка будет обнаружена и устранена, перенаправьте сопоставление API для вашего личного доменного имени обратно в HTTP API.

Подтвердите, что запрошенный ресурс существует в определении API.

Примечание. Если вы получаете ошибки при выполнении команд интерфейса командной строки AWS (AWS CLI), убедитесь, что вы используете самую последнюю версию AWS CLI.

Проверьте следующее с помощью консоли API Gateway или интерфейса командной строки AWS:

  • API развернут с последним определением API.
  • Запрошенный ресурс существует в определении API.

Используйте curl для получения сведений о запросе и ответе

Если ошибка может быть воспроизведена, используйте команду curl -v для получения дополнительных сведений между клиентом и API, как показано ниже:

 
 curl -X HTTP_VERB - v https://{api_id}.execute-api.{region}.amazonaws.com/{stage_name}/{resource_name}

Примечание: Для получения дополнительной информации посетите веб-сайт проекта curl.

Убедитесь, что заголовок запроса правильный

Если ошибка является результатом недействительного ключа API, убедитесь, что в запросе был отправлен заголовок «x-api-key» .

Убедитесь, что настройка DNS для любого интерфейса конечных точек Amazon VPC задана правильно.

Примечание. Подтвердите следующее для API, вызываемых из Amazon VPC, который имеет только конечную точку интерфейса VPC.

Убедитесь, что параметр DNS конечной точки интерфейса задан правильно в зависимости от типа используемого вами API.

Имейте в виду следующее:

  • Чтобы вызвать региональный API из Amazon VPC, частные DNS-имена должны быть деактивированы на конечной точке интерфейса. Затем имя хоста конечной точки может быть разрешено общедоступным DNS. Дополнительные сведения см. в разделе Создание частного API в Amazon API Gateway.
  • Чтобы вызвать частный API из Amazon VPC с использованием частного DNS-имени API, необходимо активировать частные DNS-имена на конечной точке интерфейса. Затем имя хоста конечной точки интерфейса можно преобразовать в ресурсы локальной подсети Amazon VPC. Дополнительные сведения см. в разделе Как вызвать частный API.
    Примечание: Вам не нужно настраивать частный DNS, если вы вызываете частный API с помощью одного из следующих способов:
    Общедоступное DNS-имя частного API.
    -или-
    Псевдоним Amazon Route 53.

Просмотрите политику ресурсов API

Просмотрите политику ресурсов вашего API, чтобы убедиться в следующем:

  • (Для API, вызываемых из Amazon VPC с конечной точкой интерфейса VPC) API.
  • Спецификации ресурсов и форматирование политики ресурсов верны.
    Примечание:
    При сохранении политики ресурсов проверка спецификации ресурса не выполняется. Примеры см. в разделе Примеры политики ресурсов шлюза API.
  • Вызывающий объект может вызывать конечную точку API в соответствии с типом проверки подлинности, который вы определили для API. Дополнительные сведения см. в разделе Как политики ресурсов шлюза API влияют на рабочий процесс авторизации.

Просмотр HTTP-запросов и ответных сообщений

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

Примечание: Для автономного анализа сохраните сообщения в файле HTTP-архива (HAR).

Информация, связанная с данной

Распространенные ошибки — Amazon API Gateway

Как разрешить только определенным IP-адресам доступ к REST API шлюза API?

Как устранить неполадки при подключении к конечной точке частного API шлюза API?

Как включить журналы Amazon CloudWatch для устранения неполадок API REST шлюза API или API WebSocket?

403 Запрещенное сообщение об ошибке — WS Form

WS Form использует WordPress REST API для сохранения и отправки форм. Это тот же API, который используется администратором WordPress, комментариями в блогах и многими другими популярными плагинами. Это предпочтительный выбор для обеспечения безопасного метода публикации данных на веб-сайте WordPress.

Если вы получаете ошибку 403 Forbidden при редактировании или использовании формы, это означает, что у вас нет разрешения на выполнение этого запроса API.

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

Вот что вы можете проверить:

Неправильная конфигурация кэширования страницы

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

Одной из возможных причин этого может быть функция WordPress под названием «NONCE» (число, используемое ОДИН РАЗ). NONCE — это уникальный код, который отправляется на ваш веб-сервер всякий раз, когда ваша форма взаимодействует с WordPress в фоновом режиме. Их предполагаемая цель — гарантировать, что данные, отправляемые на ваш веб-сайт, поступают из действительного источника, и они помогают предотвратить несанкционированный доступ к вашему веб-сайту.

Форма WS будет использовать форму NONCE при следующих условиях:

  1. Если установлен флажок «Включить NONCE» в глобальных настройках (вкладка «Дополнительно»). Этот параметр отключен по умолчанию.
  2. Если пользователь вошел в систему.

Если NONCE кэшируется слишком долго, он устаревает, и WordPress выдает ошибку 403 при отправке формы. Это не ошибка формы WS. Ошибка исходит от WordPress, когда он получает запрос POST из вашей формы. Многие современные плагины и функции WordPress используют NONCE для защиты веб-сайтов.

Значения Nonce действительны в течение 12 часов , после чего любое последующее использование этого значения приведет к ошибке.

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

Чтобы ваш веб-сайт WordPress мог правильно обрабатывать значения NONCE, мы рекомендуем кэшировать все страницы, содержащие формы, на 10 часов ИЛИ МЕНЕЕ. В большинстве случаев достаточно кэширования страниц в течение 1 часа или менее.

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

Для справки, действия NONCE, используемые WS Form:

  • wp_rest
  • wsf_post

Для получения дополнительной информации о nonces посетите: https://developer.wordpress.org/plugins/security/nonces/

LiteSpeed ​​

Если ваш хостинг использует LiteSpeed, убедитесь, что ESI (Edge SideIncludes) включен.

  • Включить ESI на уровне сервера
  • Включить ESI на уровне подключаемого модуля

мод_безопасность

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

Форма WS была протестирована со следующими наборами правил mod_security:

  • ОВАСП
  • Комодо WAF

Неправильно настроенное приложение mod_security может привести к неправильной работе WS Form и других популярных подключаемых модулей.

403 запрещенные ошибки могут быть вызваны тем, что mod_security ошибочно принимает запросы API, сделанные WS Form, как потенциальные угрозы. На самом деле, даже сохранение сообщений или страниц, содержащих определенные слова, может привести к срабатыванию mod_security для предотвращения этого запроса.

Если вы столкнулись с этим, мы рекомендуем обсудить эту проблему с вашим хостинг-провайдером и попросить его перенастроить mod_security таким образом, чтобы он не интерпретировал запросы как угрозы. Внесение собственного IP-адреса в белый список — один из вариантов.

Другой вариант — внести в белый список запросы, сделанные WS Form.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *