Home » Wordpress » Ошибка WordPress - Извините, вам не разрешено просматривать эту страницу

Ошибка WordPress - Извините, вам не разрешено просматривать эту страницу

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом "Administrator Linux. Professional" в OTUS. Курс не для новичков, для поступления нужно пройти .

Введение

Я выполнял перенос сайтов с обычного хостинга с внешним ip адресом. Сайты работали на https. Их нужно было перенести на другой хостинг, который организован немного не стандартно. Запросы сначала приходят на сервер с nginx, работающим в режиме proxy_pass. Дальше запросы по протоколу http уходят на другой сервер, где работают уже непосредственно сами сайты. На втором сервере (бэкенд) стояла связка nginx + php-fpm.

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

Сайт выполнил переадресацию слишком много раз.

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

Сайт выполнил переадресацию слишком много раз.

Сайт выполнил переадресацию слишком много раз.

Я немного удивился ошибке, но после того, как пораскинул мозгами, понял, в чем ее причина. Помог мне в этом один из заголовков главной страницы сайта во время редиректа - x-redirect-by: WordPress.

x-redirect-by: WordPress

Запрос приходит на внешний сервер по https, дальше он его перенаправляет на бэкенд по http, где работает wordpress. У него в настройках указано, что он живет по адресу с https и он на него редиректит сам. Запрос опять возвращается на proxy и так по кругу.

Я решил эту проблему следующим образом. На прокси добавил еще один заголовок.

location / {
    proxy_pass http://10.20.50.3:80;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto https;
    }

А в сам wordpress в файл wp-config.php, который лежит в корне сайта, добавил следующие строки.

if($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https'){
    $_SERVER['HTTPS'] = 'on';
    $_SERVER['SERVER_PORT'] = 443;
    }

После этого бесконечный редирект прекратился и сайт заработал. Я думал, что на этом все. Оказалось - нет. Возникла еще одна ошибка.

Извините, вам не разрешено просматривать эту страницу

При входе в админку получал вот такое сообщение.

Извините, вам не разрешено просматривать эту страницу

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

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

Указанные выше параметры из wp-config.php изначально я добавил в самый конец файла. После того, как я их перенес выше, сразу же после настроек подключения к базе, ошибка с подключением к админке: "Извините, вам не разрешено просматривать эту страницу" исчезла. Все заработало как и должно работать. Я их перенес вот сюда.

HTTP_X_FORWARDED_PROTO

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

  1. Делаешь дамп базы, кладешь его сразу же в корень сайта.
  2. На новом сервере по rsync через ssh забираешь все файлы сайта.
  3. Разворачиваешь БД из дампа, не забываешь удалить его.

Дальше остается только конфиги подготовить:

  1. Nginx
  2. Php-fpm
  3. Logrotate

Ну и на самой proxy:

  1. Nginx
  2. Certbot
  3. Logrotate
  4. Fail2ban

Перечислил, чтобы самому потом не забыть :)

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

proxy_connect_timeout 180;
proxy_send_timeout    180;
proxy_read_timeout    180;

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

Онлайн курс Основы сетевых технологий

Теоретический курс с самыми базовыми знаниями по сетям. Курс подходит и начинающим, и людям с опытом. Практикующим системным администраторам курс поможет упорядочить знания и восполнить пробелы. А те, кто только входит в профессию, получат на курсе базовые знания и навыки, без воды и избыточной теории. После обучения вы сможете ответить на вопросы:
  • На каком уровне модели OSI могут работать коммутаторы;
  • Как лучше организовать работу сети организации с множеством отделов;
  • Для чего и как использовать технологию VLAN;
  • Для чего сервера стоит выносить в DMZ;
  • Как организовать объединение филиалов и удаленный доступ сотрудников по vpn;
  • и многое другое.
Уже знаете ответы на вопросы выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов в случайном порядке. Поэтому тест можно проходить несколько раз без потери интереса. Бесплатно и без регистрации. Все подробности на странице .

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Zerox
Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству.

10 комментариев

  1. Аватар
    Николай

    Спасибо автору! Очень долго бился с этими ошибками

  2. Аватар
    Михаил

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

  3. Аватар

    Автору большое спасибо! Мне помогло исправить аналогичные ошибки

  4. Аватар
    Андрей

    Спасибо большое! Ваш опыт пригодился!

  5. Аватар

    Реально интересно. Напишите мануал по размещению сайтов wordpress за внешним проксирующим nginx плиз

    • Zerox

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

  6. Аватар

    Интересно, спасибо. )
    Сам сталкивался с подобным, но до wp-config.php тогда так и не успел добраться.
    Как вы и просили, пишу в комментарии о том, что мне интересно узнать полную схему размещения сайтов wordpress за внешним проксирующим nginx и зачем все это нужно.

  7. Аватар

    Привет,

    а я вот так фиксил
    https://dimetrius.net/linux/web-servers/ssl-mezhdu-frontendom-i-bekendom-cherez-neskolko-proksi-serverov.html

    особенность в том что это универсальное решение без правок кода скриптов.

    • Zerox

      Спасибо за ссылку. Это реально правильное решение. Я знал, что это можно сконфигурировать на сервере через настройки $fastcgi_https, но не знал как именно. А много времени тратить не хотелось. Эта настройка ключевая при конфигурации с https и проксировании запросов на бэкенды.

    • Zerox

      Не помогло это. По факту все равно приходится в разных сайтах по-разному решать этот вопрос. Я немного разобрался в предложенной схеме и не понял ее смысла. Можно было просто принудительно в параметрах fastcgi установить значение:
      fastcgi_param HTTPS on;
      и не городить огород с map. По факту сейчас все равно все сайты работают по https.

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

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.