Modx sendredirect не работает

Прямой эфир

umka 1 октября 2021, 13:42

Pathologic 22 сентября 2021, 10:34

RuSS_lan 15 сентября 2021, 12:15

levonty 12 сентября 2021, 16:05

digitz 2 сентября 2021, 15:32

marinau 31 августа 2021, 18:52

nohc 28 августа 2021, 20:02

tmih 27 августа 2021, 10:44

kymage 26 августа 2021, 15:04

Инфо о авторе топика

Топики пользователя

Вопросы

Категории

Подразделы блога

Блоги

• Готовые дополнения для MODX148
• В разработке47
• evoShop3
• Краундфандинг2
• Юмор10
• MODX Cloud8
• Социальная сеть12
• bid-cart24
• MODX custom by Dmi3yy51
• Интегрированные среды разработки (IDE)13
• Для модераторов13
• Оформления для frontend’a и backend’a41
• Быстрые решения104
• Проект MODX.im50
• Эксперименты и исследования59
• Документация и уроки63
• Форки MODX26
• Сайты на MODX47
• Tips & tricks90
• Новости71
• Безопасность83
• Обьявления о работе293
• Вопросы793

[EVO] (РЕШЕНО) Не работают редиректы

Юзаю который раз плагин RedirectMap, но в этот раз не очень успешно

Вот сам код плагина:

Почему-то редиректы некоторые работают, а некоторые нет. Например:
shop/30/30-tali-rychnie||66 — этот редирект работает

А этот не работает, выдает 403 ошибку
Но если исправить старую ссылку вот так:

shop/42/40-lebedki/41-1-lebedki-rychnie/42montajno-tyagovie-mehanizmi-mtm||85
Т.е. убираем одно тире в конце
То редирект начинает работать. Но у меня же ссылка другая, как можно исправить плагин и решить эту проблему? вручную не хочется делать (

Пробовал через htaccess
RewriteRule ^shop/58/57-bloki-montajnie/58-1-blok-montajnii-s-krukom$ bloki-montazhnyie/bloki-montazhnyie-s-kryukom.html [R=301,L]

работает, а такой же редирект через плагин нет.

Источник

Редиректы в MODX Revolution — небольшой плагин

Внесены изменения — подробнее в конце статьи.

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

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

Когда-то давным-давно, когда деревья были большими, я что-то подобное делал для какого-то клиента, но на MODX Evolution. А, я сущность хозяйственная и всё, так сказать в дом, точнее в папочки на свой накопитель. Специально использовал слово накопитель, ибо накопил там уже много разных ништяков, в виде файликов, в которых есть интересные решения той или иной задачи. Ну да, отвлёкся, наша цель редирект для MODX Revolution, спонсором данного предложения, стала местная банда SEOшников, в моём лице.

Редирект для MODX Revolution

Создаём плагин, как назвать, ну я назвал Redirect, кэп с Вами, други! Затем идем на вкладку «Системные события» и, о, как неожиданно да, ставим галку в событии OnPageNotFound . Не забываем сохранить.

Код самого плагина:

Как Вы, уже заметили в коде я вызваю чанк mapRedirect , кэп все еще с Вами, это именно карта редиректов, создаём его. И уже в нём заносим всё редиректы, которые нам нужны в следующем формате:

Да, да, я не ошибся урл или ID ресурса, видели is_numeric , вот тут и происходит магия. Определяет цифра или нет, ну и дальше уже генерирует урл через makeURL или просто использует то, что там есть.

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

Собственно, на этом всё. Успеха и отличного настроения, Вам!

П.С. Доработал, теперь работает не только с ID ресурса, но и URL (важно, урл куда идёт перенаправление, должен быть полным)

Источник

modX.sendRedirect

modX::sendRedirect¶

Отправляет перенаправление на указанный URL-адрес с помощью указанного метода.

Syntax¶

Обратите внимание, что $type и $responseCode устарели и, скорее всего, будут удалены в следующем выпуске. Не полагайтесь на них.

$url должен быть правильным url-адресом,который может быть сгенерирован с помощью modX::makeUrl для перенаправления. $options принимает массив с одной или несколькими из следующих пар ключ/значение:

• type , введите одно из следующих значений (по умолчанию используется REDIRECT_HEADER ):
  • REDIRECT_REFRESH — использует метод обновления заголовка
  • REDIRECT_META — отправляет на выход тег META HTTP-EQUIV=»Refresh»
  • REDIRECT_HEADER — использует метод расположения заголовка
• responseCode , который должен быть правильным ответом HTTP, так что не только «301» или «302». По умолчанию «HTTP/1.1 302 перемещается временно», но вы можете установить его в «HTTP/1.1 301 перемещается постоянно» для перенаправления в стиле 301.
• count_attempts указывает количество попыток перенаправления перед остановкой.

$type, который является устаревшим и не должен использоваться, совпадает с типом ключа массива $options. $responseCode, который является устаревшим и не должен использоваться, совпадает с ключом массива responseCode $options

Примеры¶

Отправьте запрос перенаправления на ресурс с идентификатором 54.

Отправить редирект на modx.com. сделайте это с помощью метатега HTTP-EQUIV refresh.

Отправьте код ответа «301 перемещенный постоянно» вместо кода ответа «302 перемещенного временно» по умолчанию.

Источник

modX.sendRedirect

modX::sendRedirect¶

Отправляет перенаправление на указанный URL-адрес с помощью указанного метода.

Syntax¶

Обратите внимание, что $type и $responseCode устарели и, скорее всего, будут удалены в следующем выпуске. Не полагайтесь на них.

$url должен быть правильным url-адресом,который может быть сгенерирован с помощью modX::makeUrl для перенаправления. $options принимает массив с одной или несколькими из следующих пар ключ/значение:

• type , введите одно из следующих значений (по умолчанию используется REDIRECT_HEADER ):
  • REDIRECT_REFRESH — использует метод обновления заголовка
  • REDIRECT_META — отправляет на выход тег META HTTP-EQUIV=»Refresh»
  • REDIRECT_HEADER — использует метод расположения заголовка
• responseCode , который должен быть правильным ответом HTTP, так что не только «301» или «302». По умолчанию «HTTP/1.1 302 перемещается временно», но вы можете установить его в «HTTP/1.1 301 перемещается постоянно» для перенаправления в стиле 301.
• count_attempts указывает количество попыток перенаправления перед остановкой.

$type, который является устаревшим и не должен использоваться, совпадает с типом ключа массива $options. $responseCode, который является устаревшим и не должен использоваться, совпадает с ключом массива responseCode $options

Примеры¶

Отправьте запрос перенаправления на ресурс с идентификатором 54.

Отправить редирект на modx.com. сделайте это с помощью метатега HTTP-EQUIV refresh.

Отправьте код ответа «301 перемещенный постоянно» вместо кода ответа «302 перемещенного временно» по умолчанию.

Источник

Серверы с mod_security

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

ModSecurity (aka mod_security или mod_sec)¶

ModSecurity — это брандмауэр веб-приложений с открытым исходным кодом, который работает как серверный модуль Apache. Он реализует исчерпывающий набор правил, реализующих усиление защиты общего назначения, и тем самым помогает исправлять распространенные проблемы безопасности веб-приложений. Он устанавливает внешний уровень безопасности, который повышает безопасность, обнаруживает и предотвращает атаки до того, как они достигнут веб-приложений. Он обычно доступен в системах cPanel как модуль EasyApache. Это хорошо зарекомендовавший себя модуль безопасности, который действительно может помочь защитить ваш сайт от распространенных векторов атак.

Мы подробно обсуждаем ModSecurity здесь, потому что менеджер MODX Revolution выдает много запросов, которые могут противоречить правилам mod_security .

Тихий убийца¶

Менеджер MODX может просто спокойно выйти из строя, если одно из его действий заблокировано mod_security . Знай свой сервер! Проверьте журналы ошибок Apache! На карту поставлено ваше здравомыслие!

Как я узнаю, что у меня установлен ModSecurity?¶

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

Если у вас есть собственный сервер (например, созданный на основе шаблона VPS), вы можете войти на сервер и проверить это самостоятельно.

Проверка на сервере WHM¶

Многие VPS включают административные панели WHM/cPanel. Относительно легко проверить, запускаете ли вы mod_security на сервере WHM.

1. Войдите в свой экземпляр WHM (обычно по адресу https://yoursite.com:2087/).
2. Найдите раздел «Плагины» на левой панели навигации.
3. Если ModSecurity установлен, вы увидите Mod Security в списке ваших плагинов.

Удобный модуль cPanel/WHM mod_security доступен для визуального редактирования ваших правил здесь: http://configserver.com/

Проверка через командную строку¶

Если у вас есть SSH-доступ к вашему серверу, вы можете проверить, какие модули Apache загружает при запуске. Чтобы распечатать, какие модули загружены в Apache, вы можете использовать утилиту apachectl в системах *NIX, например

Или, если ваша команда apachectl отсутствует в вашем текущем $PATH , вам может потребоваться указать полный путь к утилите. Чтобы найти путь, вы можете найти его с помощью команды find:

Затем, когда вы найдете полный путь к утилите, вы можете выполнить команду подробно, например:

Результат будет примерно таким:

Модуль mod_security указан как security2_module

Другой разведчик¶

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

1. Проверьте основной файл Apache (часто находится тут /etc/httpd, например /etc/httpd/conf/httpd.conf)
2. Проверьте дополнительные каталоги конфигурации (часто внутри подпапок основного каталога конфигурации).

Лог-файлы¶

После того, как вы убедились, что ModSecurity действительно запущен, вы захотите проверить свои журналы, чтобы увидеть, действительно ли ваши действия в диспетчере MODX вызывают срабатывание сигнализации системы безопасности. Лучше всего это сделать через командную строку: используйте SSH для входа на свой сервер и убедитесь, что у вас есть соответствующий доступ (например, привилегии root) для просмотра этих файлов журнала.

Основной журнал, за которым вы хотите следить, — это журнал ошибок Apache. Точное расположение настраивается в вашем файле конфигурации Apache, но часто оно находится внутри /usr/local/apache/logs/error_log. Хороший способ просмотреть этот файл — использовать утилиту tail. Вы можете отслеживать файл в режиме реального времени, используя флаг -f, например

Держите это окно открытым при навигации по диспетчеру MODX и будьте начеку, если в этом файле появятся какие-либо ошибки. (Нажмите ctrl-C, чтобы закрыть утилиту).

Вы также можете посмотреть содержимое журнала mod_security . Опять же, местоположение можно настроить, но часто оно сохраняется в /usr/local/apache/logs/modsec_audit.log

Пример ошибки¶

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

Вот пример ошибки из журнала ошибок Apache:

Из этой ошибки нам нужно 3 части информации, чтобы внести конкретное действие в белый список. Обратите внимание на следующие 3 пункта:

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

Внесение правила для домена в белый список¶

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

Восстановите конфигурацию Apache¶

Первое, что нужно сделать, — это создать резервную копию и перестроить файл httpd.conf, чтобы убедиться в отсутствии ошибок (выполните следующие команды по очереди)

Если вы используете сервер cPanel, вы можете перестроить файл, выполнив следующую команду:

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

Отредактируйте файл виртуальных хостов¶

Многие настройки (включая настройки cPanel) не хотят, чтобы вы возились напрямую с основным файлом конфигурации Apache. Вместо этого вы отредактируете файл vhosts для данного домена. Просмотрите свой основной файл конфигурации Apache (httpd.conf) и найдите свое доменное имя, чтобы узнать, куда он передал свои файлы конфигурации. Вы должны найти некоторые ссылки на него внутри блока VirtualHost.

Основываясь на этой директиве VirtualHosts, мы можем обратить внимание на 2 указанных каталога:

Вы также можете установить общие серверные правила в файле:

Вот где Apache будет искать дополнительные конфигурации. Если вы знаете, что вам не нужно беспокоиться о дополнительных файлах конфигурации, вы можете перейти к следующему разделу и просто добавить свои правила белого списка. Если вы работаете на сервере cPanel или используете какой-либо другой тип настройки, при котором вы либо не можете, либо не должны редактировать основной файл httpd.conf напрямую, тогда вам следует поместить свои правила в отдельный файл конфигурации. Возможно, вам потребуется создать каталоги, перечисленные выше, или, возможно, вам придется немного выполнить rtfm, чтобы выяснить, где Apache будет искать дополнительные файлы конфигурации.

Добавить правило белого списка¶

Общий пример¶

Общее правило белого списка выглядит так:

Вы можете изменить его и добавить в свою директиву VirtualHosts (либо в вашем основном httpd.conf, либо во внешних vhosts.conf файлах). Пока Apache загружает файл конфигурации, правило белого списка будет зарегистрировано.

Конкретный пример¶

Приведите наш пример сообщения об ошибке ранее, в котором указана следующая ошибка:

Мы могли бы перейти к директиве VirtualHosts для yoursite.com и добавить следующее правило:

Обратите внимание, что он ссылается на коннектор MODX по его пути и ссылается на правило ModSecurity по его идентификатору.

Остерегайтесь перемещения вашего сайта¶

Если вы переместите свой сайт в новый каталог или каталог ** коннекторов ** в нестандартное место, вам придется отредактировать свои правила! Они применяются к определенному URL-адресу, поэтому, если ваши URL-адреса изменятся, правила придется обновить.

Более широкий пример¶

Может быть неприятно просматривать функциональность MODX по одному экрану администратора за раз, но, похоже, есть некоторые трудности с занесением в белый список целых каталогов. Подумайте о переименовании вашего каталога «коннекторов» (см. Укрепление MODX Revolution).

Перезагрузите Apache¶

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

cPanel: перестроить файл Conf¶

Если вы не используете сервер cPanel, пропустите этот шаг и просто перезапустите Apache.

На сервере cPanel вы захотите повторно запустить утилиту rebuildhttpdconf:

Затем вы можете проверить, внесены ли изменения, внесенные вами во внешние файлы, в основной файл (опять же, это ТОЛЬКО при настройке cPanel: cPanel вносит внешние конфигурации в основной файл httpd.conf). Попробуйте просмотреть файл, чтобы увидеть, что все, что вы поместили во внешний файл, теперь включено в основной файл.

Перезагрузите Apache¶

После внесения изменений перезапустите процесс Apache:

Если в ваших файлах есть ошибки, вы будете предупреждены о них. Это может нервировать, потому что, если Apache не вернется в сеть, ваш сайт будет недоступен!

Статические ресурсы¶

ModSecurity может повлиять на ваши статические ресурсы MODX (или любой PHP-скрипт, который читает файл для загрузки пользователем). Что может случиться, так это то, что если ваш файл слишком большой, загрузка будет преждевременно прервана, и вы получите поврежденный файл. Часто размер загруженного файла составляет всего около 64 КБ, даже если исходный файл может быть значительно больше. Если вы столкнулись с этим, это может быть хорошим намеком на то, что ModSecurity вмешивается. Для этого может не быть записи в журнале (. ), поэтому может быть очень сложно отследить это поведение обратно в ModSecurity!

В WHM вы можете редактировать параметры конфигурации ModSecurity, щелкнув ссылку плагина «Mod Security» (изображенную ранее на этой странице) и нажав кнопку «Изменить конфигурацию».

Детали конфигурации, которые могут повлиять на ваши загрузки, следующие:

• SecRequestBodyAccess
• SecRequestBodyLimit
• SecRequestBodyInMemoryLimit

Простое решение — полностью обойти ModSecurity для таких загрузок:

Другой причиной этого загадочного симптома может быть конфликт между веб-серверами: например, если у вас установлены Apache и NGINX на одном сервере, _ убедитесь, что они оба не используют сжатие gzip_ — результат может быть очень похож на вмешательство ModSecurity! Если NGINX сжимает большой статический ресурс, а затем Apache также пытается его сжать, это не удается, и файл заканчивается обрезанием до 64 КБ.

Источник