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

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

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

Углубленный онлайн-курс по MikroTik

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Введение

Я выполнял перенос сайтов с обычного хостинга с внешним 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;

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

Углубленный онлайн-курс по MikroTik.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

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

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

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

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

  1. Благодарю, Помогли!

  2. Сергей

    У меня эта же проблема возникла из за префикса БД "ЗАГЛАВНЫМИ БУКВАМИ"
    При экспорте БД префикс таблиц перевелся автоматом в маленькие буквы, а в таблице usermeta остались несколько ЗАГЛАВНЫХ.
    Получилось я как бы залогинился но не полностью )))
    Исправил все на маленькие и вошел нормально.

  3. Благодарю, помогли.

  4. Спасибо тебе, добрый человек. Чуть кукушечкой не тронулся, и конфги по пять раз перепроверил, и пробовал поставить на http, а потом переключить на https. А самое главное, четкой инфы кроме твоей стать не нашел, чтоб без лишнего хлама. Спасибо ещё раз.

  5. Аноним

    Спасибо!

  6. Николай

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

  7. Михаил

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

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

  9. Андрей

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

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

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

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

  12. Привет,

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

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

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

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

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

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

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.
Используешь Telegram? Подпишись на канал автора →
This is default text for notification bar