Безопасность CMS на PHP

Absolute

Разрушитель (V)
Сообщения
54
Симпатии
33
Баллы
249
Предыстория вопроса:
Популярные CMS, написанные на PHP, хороши тем, что при низких бюджетах на проект позволяют выдавать сайты с требуемым функционалом. Тебе просто не надо бОльшую часть функционала писать т.к. часто он уже написан в виде какого-нибудь дополнения.
Вместе с тем - как быть с проектами, где безопасность играет ключевую роль и которые 100% кто-нибудь (весьма квалифицированный) заморочается и начнет ломать (банки, сайты знакомств, проекты с биллингами, обменники и т.д.). Примеров сайтов, требующих повышенную безопасность может быть масса.
Опять же - бюджеты низкие, особенно на старте, а безопасность нужна высокая, а в некоторых случаях параноидальная. Хотя, разумеется, банки не попадают под категорию "низких бюджетов на старте".

Возможно, не следует использовать CMS, а тем более на PHP??
Казалось бы еще не так давно SECL GROUP рапортовала: Более трети российских банков предпочитают «1С-Битрикс»
Хотя публикация и не свежая, но пробежавшись по списку, действительно можно обнаружить, что на Битриксе работают до сих пор:
  • Корпоративный сайт управляющей компании Сбербанк;
  • Россельхозбанк;
  • Банк Россия;
  • Банк Траст;
  • Московский Индустриальный Банк;
  • Кредит Европа Банк;
Это далеко не самые последние игроки финансового рынка. То есть CMS - написанная на PHP, всё же может обеспечить хороший уровень безопасности?
Вместе с тем, посмотрев исходный код страничек сайтов других банков из этой публикации - можно увидеть, что к настоящему времени они перешли на другие технологии - Node.js или что-то еще.

Подавляющее число взломов - из-за чего?
Из моего опыта складывается, что чаще всего ломают из-за недостаточной фильтрации данных. SQL-инъекции соответственно сюда же. Поправьте меня, если это не так.
Показателен пример уязвимости в библиотеке PHPMailer, которую использует WordPress, описанный летом.
Или знаменитый фейл Iqitcommerce - именитого разработчика Warehouse для PrestaShop (в сети есть инфа). Была дыра, через которую тебе одновременно несколько хакеров лили всё, что хотели)) Тогда под раздачу и я попал.
Перечислять обнаруженные и описанные дырки можно до бесконечности. И сколько еще не обнаружено.

Собственно, что делать??
Как максимально обезопасить какую-то CMS с кучей библиотек, модулей, плагинов, когда ты не знаешь где именно "прорвет"??

1. Пришла в голову мысль изменить структуру CMS (какой-то) так, чтобы в корне был только index.php и папки со статикой с минимальным набором прав, а всю структуру со скриптами размещать выше корня и роутить соответственно с index.php по дереву выше. Если грубо , идея состоит в том, что если где-то и есть уязвимость, то по крайней мере до нее нельзя будет дотянуться из адресной строки. Или это плохая идея и я чего-то не учел??
2. Не менее "гениальная мысль" - файлы, которые льет юзер - запретить их запрос с домена, на котором исполняется PHP, а сделать что-то вроде cdn (без PHP - только статика) и при попытке любого доступа к папке uploads с основного домена - перенаправлять на cdn.domain.ru через nginx, apache (без разницы). Понятно, можно запретить выполнение скриптов в данной папке, как это везде делают - достаточно ли одного этого?
3. Не размещать админа в таблице со всеми юзерами, как это в Joomla. Вообще не размещать админа в БД. Наверное лучше?
4. Для nginx - в сети много фильтров SQL-инъекций... Но! Это, как понимаю, только для GET-запросов? Как быть с POST? Перебирать всё куда может прилететь POST и ставить дополнительные проверки?
5. Ваши мысли... ))))
 
Последнее редактирование:
Nginx можно настроить на выполнение пхп кода только index.php и только в указанной директории.
 
Из моего опыта складывается, что чаще всего ломают из-за недостаточной фильтрации данных. SQL-инъекции соответственно сюда же. Поправьте меня, если это не так.

Поправляю. Основная проблема взломов - отсутствие либо недостаточная фильтрация входящих данных (отсутствие проверок на структуру и тип получаемых данных, легкомысленное отношение к получаемым данным).
 
Есть такая штука, как filter_var и иже с ней (и целые гайды по безопаности). О безопасности подумали, но на нее забили программисты) Банки как таковые используют гибридные ОС (там своя неведомая зверушка) + контенеризацию. С Joomla была долгое время проблема в том, что: а) они давно и плотно забили на просмотр веток с комиттами исправлений, еще на нульке писал: проблема в Null Day была описана за год до, ветки терлись. Битрикс отличается тем же самым (очень трудно комиттить правки ядра). Но ломают да, меньше. Там есть собственный анализатор качества кода (что в принципе не плохо, бывают интересные подсказки).

Ремарка: идеальная защита по стоимости взлома превосходит стоимость самого проекта, вас все равно взломают... (из лекции по Защите информации с ограниченным доступом в моем университете 15 лет назад:)

Все описанное ниже защитит Вас от 80% начинающих хакеров и взлома автоматическими средствами. Плюс поможет избавиться от головной боли при разгребании последствий. Набито множеством шишек клиентов и собственными шишками.

О сервере:

В целом лучше иметь два виртуальных контейнера. SQL отдельно (без php и возможности выполнить залитый файл), PHP отдельно (без sql). Также, если есть сомнения, закажите аналитику безопасности. Из автоматических шняг есть тот же acunetix (профи подскажут больше, я в этом плане любитель). И делайте ее время от времени. К этому добавлю: безопасность != хостинг. Вас могут ломануть из-под соседей. Т.е. 1 сайт = 1 виртуальный контейнер. И да, придется просматривать логи время от времени. И да, придется удалить все, что не нужно в плане сервисов. Пример: зачем вам сервер почты, если сайт не предусматривает получение почты с доменных ящиков? Зачем открытая прослушка его портов?

Если нервы позволяют, рекомендую ознакомиться с SE Linux и ее аналогами.

Также должна обновляться (периодически) и сама cms, и os сервера (контейнера), и ос бд (контейнера).
Доступ по ssh должен быть закрыт по ключу.
Права на файлы должны быть минимальны из возможных.
PHP и командные скрипты не должны выполняться из под пользователя/группы с правами root или с повышением прав к root.
Что можно еще сделать? Например: если идут изменения в файлы, проверять время от времени src чистых файлов. Что-то изменилось, оповещать письмом и откатывать. В пользовательских папках загрузки не должны выполняться скрипты. Вообще и никак.
Также взломщику на основном сервере может попудрить мозги большое время opcache (у него все получится, но он некоторое время не увидит результатов собственных действий:).
Сервер должен откровенно "врать" в заголовках о своем п.о. или молчать о нем (заголовки ответа).
Ошибки (даже не критические) не должны выводиться пользователю. Только запись в логи ос.
Есть сканеры вирусов/шеллов и т.п. Они также должны (вместе с антивирусом) работать на сервере с оповещением причастных в заданный период.
Есть файрволлы, которые позволяют вычислить автоматическую проверку на уязвимости и принять решение по умолчанию в этом случае.
Всякие интерфейсы к б.д. должны быть закрыты под дополнительной авторизацией. Вспомним уязвимости в phpmyadmin.

О коде:

Все include, require должны быть жестко привязаны к путям сервера.
Ничего не должно подключаться (include, require) из GET, REQUEST, COOKIE и даже SERVER нужно проверять. Если на этом строится пользовательский интерфейс, проверять конкретные значения через switch, и там принимать решение: что подключать/куда бежать/что делать.
Авторизация закрыта рекапчей (плюс любые отправки сообщений).
Админ не должен иметь тривиальный логин (admin, например) и тривиальный id.
Он не должен иметь возможность коннектиться с фронта.
Не должны быть доступны извне без авторизации файлы, которые выполняют системные функции и phpinfo.
Все, что указывает на версию CMS с доступом извне, должно быть удалено.
Админка должна быть закрыта не тривиальным GET ключом. Иначе: 404.
Никогда не оставляйте в папке сайтов также и другие скрипты, например: adminier, mysqldumper, syphex dumper и т.п. Для всего этого есть localhost и закрытый dev.

Если вас уже взломали:

Как минимизировать последствия взлома? Git + бекап (периодический, вне хоста, где сайт!)
Нужно иметь вариант быстрого отката к стабильной версии с наименьшими потерями. Бережет нервы.

Удачи Вашим проектам.

Если будет пробегать хороший администратор/аналитик по безопасности, может существенно добавить/исправить/что-то расписать. Сам буду рад почитать и скажу спасибо!
 
Последнее редактирование:
А у меня на эту тему вопрос по Joomla. Обычно для защиты админки ставят разные плагины, или компоненты, которые для маскировки просто удлиняют путь в адресной строке, но каждый раз строка начинается одним и тем же текстом http://сайт/administrator...
Так вот вопрос: почему нельзя взять и изменить наименование папки Administrator, на любую другую без каких-либо плагинов? Или можно?
Если возможно, то будут-ли проблемы с установкой приложений?
 
Последнее редактирование:
А у меня на эту тему вопрос по Joomla. Обычно для защиты админки ставят разные плагины, или компоненты, которые для маскировки просто удлиняют путь в адресной строке, но каждый раз строка начинается с той же строки http://сайт/administrator...
Так вот вопрос: почему нельзя взять и изменить наименование папки Administrator, на любую другую без каких-либо плагинов? Или можно?
Если возможно, то будут-ли проблемы с установкой приложений?
А зачем? Если ваша админка уже закрыта (не известен GET параметр). Проблем будет много. Даже после замены administrator будут проблемы с админкой разных плагинов и компонентов.
 
Даже после замены administrator будут проблемы с админкой разных плагинов и компонентов.
Чтобы не заморачиваться дополнительными плагинами по защите той же админки.
К примеру, на J3 у меня всё работало и я не вспоминал о плагине, но на J4 плагин приказал долго жить... потом появится J5 и снова костыль? Или какой конфликт с другими расширениями? :)
В общем интерес был по минимизации обвесов на голую Жумлу и спрятать адрес на админку от греха подальше. Жаль, что нет такой штатной возможности... было бы не плохо! Вроде где-то слышал, что можно маскировать через .htaccess, но не знал, как будут вести себя плагины и компоненты...
 
Последнее редактирование:
Благодарю всех... Рад, что тема оказалась актуальная не только для меня одного))
Попробовал по-быстрому интереса ради закинуть Joomla выше корня (public_html) - посмотреть - заведется/нет. Получилось соответственно:
Код:
-administrator
-api
-cache
-cli
-components
-и т.д по списку всё из корня Joomla
-public_html
 -- index.php
 -- templates
В index.php соответственно было:
Код:
require_once dirname(__FILE__) . '/includes/app.php';
Стало:
Код:
require_once '../includes/app.php';
И... Всё работает)) Ну, почти. Главная страница заработала сразу, а остальное заработало после активации sef. При беглом тестировании - всё ок, в логах ошибок не видно. Интересно, почему мне не встретилась ни одна CMS применяющая такой подход... Может быть я что-то не учитываю? Ведь идеальный вариант (размещать выше корня) - из адресной строки не до чего не дотянуться + значительно сложнее идентифицировать, что за CMS.

Чтобы не заморачиваться дополнительными плагинами по защите той же админки.
Самый простой способ - HTTP-авторизация, но это так себе защита. Вообще папка administrator в Joomla - большая проблема. К ее моделям обращаются некоторые компоненты с фронта - тот же Virtuemart.
 
Последнее редактирование:
Благодарю всех... Рад, что тема оказалась актуальная не только для меня одного))
Попробовал по-быстрому интереса ради закинуть Joomla выше корня (public_html) - посмотреть - заведется/нет. Получилось соответственно:
Код:
-administrator
-api
-cache
-cli
-components
-и т.д по списку всё из корня Joomla
-public_html
 -- index.php
 -- templates
В index.php соответственно было:
Код:
require_once dirname(__FILE__) . '/includes/app.php';
Стало:
Код:
require_once '../includes/app.php';
И... Всё работает)) Ну, почти. Главная страница заработала сразу, а остальное заработало после активации sef. При беглом тестировании - всё ок, в логах ошибок не видно. Интересно, почему мне не встретилась ни одна CMS применяющая такой подход... Может быть я что-то не учитываю? Ведь идеальный вариант (размещать выше корня) - из адресной строки не до чего не дотянуться + значительно сложнее идентифицировать, что за CMS.
Там тема была по безопасности рядом. Так вот: низзя так делать include ../. Привязывайтесь вообще к точным путям, не к относительным при include/require. Вплоть до константы путей, как в Opencart. Я встречал шибко параноиков, которые даже проверяют stripos(__DIR__,$_SERVER['DOCUMENT_ROOT']) === false и в исключение, если нет частичного совпадения, или в die.

Чтобы не заморачиваться дополнительными плагинами по защите той же админки.
К примеру, на J3 у меня всё работало и я не вспоминал о плагине, но на J4 плагин приказал долго жить... потом появится J5 и снова костыль? Или какой конфликт с другими расширениями? :)
В общем интерес был по минимизации обвесов на голую Жумлу и спрятать адрес на админку от греха подальше. Жаль, что нет такой штатной возможности... было бы не плохо! Вроде где-то слышал, что можно маскировать через .htaccess, но не знал, как будут вести себя плагины и компоненты...
Вам этот плагин и ему подобный обойдется в 1 час работы Joomla программиста от версии к версии. Всего 1 час до смены следующей версии, это если автор плагина не портирует код сам на следующую версию бесплатно. Экономия?
 
Там тема была по безопасности рядом. Так вот: низзя так делать include ../. Привязывайтесь вообще к точным путям, не к относительным при include/require. Вплоть до константы путей, как в Opencart. Я встречал шибко параноиков, которые даже проверяют stripos(__DIR__,$_SERVER['DOCUMENT_ROOT']) === false и в исключение, если нет частичного совпадения, или в die.
Ну, это не проблема. А есть примеры когда инклуд по относительным путям приводил к взлому? Как это эксплуатировать я чет не догоню. Очевидно, должен совпасть еще какой-то фактор?

Можете сказать - есть смысл размещать CMS выше корня сайта или это я фигню какую-то придумал и никто так не делает и заморачиваться соответственно не стоит в этом направлении? ))
 
Последнее редактирование:
Вообще папка administrator в Joomla - большая проблема.
Вот и я о том же! Неужели сложно было при установке указать своё имя папки панели администрирования? Ведь можно было бы без проблем так сделать, а VM и другие компоненты могли бы брать значение из переменной. Уже столько глобальных изменений было, а эту папку всё тянут от самой мамбы и она как кость в горле, вечно сторонними компонентами прятать приходится, а HTTP-авторизации считаю не достаточно, да и даже не в этом дело, она же палит саму CMS!

Попробовал по-быстрому интереса ради закинуть Joomla выше корня
Что-то на J3 у меня ерунда получилась...
Так вот: низзя так делать include
...теперь понятно почему.

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

В общем нашел такую тему, что в .htaccess находим RewriteEngine On и после этой строки вставляем код:
Код:
RewriteCond %{HTTP_COOKIE} !antihack
RewriteCond %{REQUEST_URI} ^/administrator [NC]
RewriteRule .? - [F]
RewriteCond %{REQUEST_URI} ^/secretfolder$
RewriteRule .? /administrator/ [CO=antihack:1:%{HTTP_HOST},R=303,L]
, где antihack - устанавливаемая кука (указывается в двух местах)
и secretfolder - наша папка на админку
В результате ссылка на админку должна получиться следующей: http://сайт/secretfolder
Надеюсь никто не будет против источника, там же и для Wordpress подсказка имеется.
 
Последнее редактирование:
Что-то на J3 у меня ерунда получилась...
В смысле не открывается сайт? А в логах что? Я тестировал Joomla_4.0.3-Stable.
Joomla_3.10.2-Stable - работает. Хотя поменять чуть больше.
index.php
Код:
<?php
/**
 * @package    Joomla.Site
 *
 * @copyright  (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>
 * @license    GNU General Public License version 2 or later; see LICENSE.txt
 */

/**
 * Define the application's minimum supported PHP version as a constant so it can be referenced within the application.
 */
define('JOOMLA_MINIMUM_PHP', '5.3.10');

if (version_compare(PHP_VERSION, JOOMLA_MINIMUM_PHP, '<'))
{
    die('Your host needs to use PHP ' . JOOMLA_MINIMUM_PHP . ' or higher to run this version of Joomla!');
}

// Saves the start time and memory usage.
$startTime = microtime(1);
$startMem  = memory_get_usage();

/**
 * Constant that is checked in included files to prevent direct access.
 * define() is used in the installation folder rather than "const" to not error for PHP 5.2 and lower
 */
define('_JEXEC', 1);

if (file_exists('/var/www/site.ru/data/www'. '/defines.php'))
{
    include_once '/var/www/site.ru/data/www'. '/defines.php';
}

if (!defined('_JDEFINES'))
{
    define('JPATH_BASE', '/var/www/site.ru/data/www');
    require_once JPATH_BASE . '/includes/defines.php';
}

require_once JPATH_BASE . '/includes/framework.php';

// Set profiler start time and memory usage and mark afterLoad in the profiler.
JDEBUG ? JProfiler::getInstance('Application')->setStart($startTime, $startMem)->mark('afterLoad') : null;

// Instantiate the application.
$app = JFactory::getApplication('site');

// Execute the application.
$app->execute();
 
Последнее редактирование:
В смысле не открывается сайт? А в логах что? Я тестировал Joomla_4.0.3-Stable.
J3.10.2 на хостинге ошибку 403 выдала, может ошибся где-то. Не стал заморачиваться, вернул все на исходную (спасибо за пример, потом ещё раз попробую), но если этот вариант тоже работает, тогда почему нельзя так делать?
А вот вариант с куки мне понравился, - работает и похоже, что это простое и отличное решение, не требующее каких-либо расширений.
 
Последнее редактирование:
J3.10.2 на хостинге ошибку 403 выдала, может ошибся где-то.
Можно попробовать включить sef:
1. в configuration.php
Код:
    public $sef = '1';
    public $sef_rewrite = '1';
2. Поместить .htaccess на один уровень с index.php в корень, не забыв переименовать, если кончается на .txt
Почему-то внутренние страницы без чпу, а также обращение site.ru/index.php - выдают 404 - пока не понял почему. С sef всё таинственным образом начинает работать. Впрочем, это пока просто эксперименты "на скорую руку", чем полноценное тестирование.
но если этот вариант тоже работает, тогда почему нельзя так делать?
Вот и я гадаю - почему так не делают. Возможно, чтобы не напрягать юзера при установке системы?
 
Ну, это не проблема. А есть примеры когда инклуд по относительным путям приводил к взлому? Как это эксплуатировать я чет не догоню. Очевидно, должен совпасть еще какой-то фактор?

Можете сказать - есть смысл размещать CMS выше корня сайта или это я фигню какую-то придумал и никто так не делает и заморачиваться соответственно не стоит в этом направлении? ))
Привожу очень простой пример.
Ваш сервер работает в папке /site.ru/web/index.php
В нем делаем:
<?php include '../app/index.php'; ?>
Выше лежит /site.ru/app/index.php
Если потенциальный хакер прочтет пути по соседству и сможет увидеть код, то в своем пространстве имен /some.site/ он создает папку /some.site/app/
В index.php которой кладет не безопасный код
А дальше делает вот так:
<?php require_once '/site.ru/web/index.php'; ?>
И выполняет в рамках своего домена.
Угадайте, из какой папки будет подключен ../app/index.php в этом случае?
Правильно! some.site/app/index.php
А про...кол с хостером, который дает посмотреть, что живет выше document_root и дает просмотреть файлы соседей по группе: тема очень старая (sweb ушка, милый, ау....). Но до сих пор актуальная. Поэтому и пишу: 1 сайт - 1 отдельный вирт. контейнер. И только привязанные абсолютные пути подключений в константах.

К вопросу о размещении библиотек CMS выше корня сайта. Есть такая буква, это особенно относится к скриптам, которые не должны сами выполняться отдельно через домен. Пример: opencart и его папка модификаций, крон и служебные скрипты. Также можно вытянуть выше папку временных загрузок. Но в целом есть и другие подходы. Например: если нет константы пути, не выполнять код далее.

Вот и я о том же! Неужели сложно было при установке указать своё имя папки панели администрирования? Ведь можно было бы без проблем так сделать, а VM и другие компоненты могли бы брать значение из переменной. Уже столько глобальных изменений было, а эту папку всё тянут от самой мамбы и она как кость в горле, вечно сторонними компонентами прятать приходится, а HTTP-авторизации считаю не достаточно, да и даже не в этом дело, она же палит саму CMS!


Что-то на J3 у меня ерунда получилась...

...теперь понятно почему.


Сначала найти плагин, или программиста, затем внедрить в свой сайт, в соседний сайт, в сайт знакомому... потом найди на другой плагин программиста... ох... кажется это уже не одним часом попахивает. В итоге новые поиски плагина.

В общем нашел такую тему, что в .htaccess находим RewriteEngine On и после этой строки вставляем код:
Код:
RewriteCond %{HTTP_COOKIE} !antihack
RewriteCond %{REQUEST_URI} ^/administrator [NC]
RewriteRule .? - [F]
RewriteCond %{REQUEST_URI} ^/secretfolder$
RewriteRule .? /administrator/ [CO=antihack:1:%{HTTP_HOST},R=303,L]
, где antihack - устанавливаемая кука (указывается в двух местах)
и secretfolder - наша папка на админку
В результате ссылка на админку должна получиться следующей: http://сайт/secretfolder
Надеюсь никто не будет против источника, там же и для Wordpress подсказка имеется.
При миграции разных версий поверьте: этот плагин - самая мелкая из проблем. Вы ее почти не заметите. А как вы палите cms? Если папка administrator без GET параметра возвращает 404? Ст. страницу apache или делает 301 на главную перенаправление?
 
Последнее редактирование:
Возня, конечно, с размещением выше корня(( Переключился с апача на nginx+php-fpm. php73 (FastPanel). Joomla_3.10.2
По итогу в корне сайта один лишь index.php с 444 правами остался, остальное прописал алиасами в конфиге nginx. При этом работает и с включенным ЧПУ, и с отключенным.
Админка теперь доступна: site.ru/test_12345/
index.php соответственно лежит в /var/www/usertest/data/www/site.ru/
Код:
  # алиас админки с выполнением php
  location /test_12345 {
        alias /var/www/usertest/data/www/administrator/;
        index index.php index.html;
            location ~ \.php$ {
              fastcgi_pass unix:/var/run/usertest.sock;
              fastcgi_param  SCRIPT_FILENAME  $request_filename;
              include /etc/nginx/fastcgi_params;
            }
    }
   
    # алиасы статики
    location /images {
        alias /var/www/usertest/data/www/images/;
    }
    location /media {
        alias /var/www/usertest/data/www/media/;
    }
    location /templates {
        alias /var/www/usertest/data/www/templates/;
    }
   
    # запросы
    location / {     
        index index.php index.html;
        try_files $uri $uri/ /index.php?$args;
    }
   
    # заставляем выполняться только /index.php
    location ~ \.php$ {
        rewrite ^ /index.php last;
     }
    
     # высокий приоритет - секция отработает раньше предыдущей при index.php
     location = /index.php {
         fastcgi_pass unix:/var/run/usertest.sock;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
         include /etc/nginx/fastcgi_params;
     }
И хотя в директориях , на которые ссылаются алиасы статики - итак не выполнится PHP-файл, даже если его туда специально поместить. Наверное можно еще взять такую секцию с оф.сайта Joomla:
Код:
    location ~* /(images|cache|media|logs|tmp)/.*\.(php|pl|py|jsp|phtml|sh|cgi)$ {
                return 403;
                error_page 403 /403_error.html;
    }
Основной геморрой по итогу - с путями administrator. Они там наглухо прописаны в формах, типа:
Код:
<form action="/administrator/index.php" method="post" id="form-login" class="form-inline">
Если ручками заменять эти пути в коде элемента - то работает. А так много где запросы отправляются в /administrator - то есть в никуда.

PS: как на Apache такое провернуть - не знаю.
 
Последнее редактирование:
Основной геморрой по итогу - с путями administrator. Они там наглухо прописаны в формах, типа:
Код:
<form action="/administrator/index.php" method="post" id="form-login" class="form-inline">
Если ручками заменять эти пути в коде элемента - то работает. А так много где запросы отправляются в /administrator - то есть в никуда.

PS: как на Apache такое провернуть - не знаю.
Есть такая класная штука у nginx http://nginx.org/ru/docs/http/ngx_http_sub_module.html
 
Можно попробовать проксировать все запросы в админке через jquery (это для ajax) и/или заменять все href тем же jquery
Если вы об Apache , то админка на одном уровне с корневой папкой, как и вся CMSка - иначе дофига чего придется перелопачивать в CMSке. Опять же одну админку в корень возвращать - не вариант, да и не заработает она там просто так. Ну, то есть до админки - не достучаться с фронта, если переключиться на Апач))
Да и остальные алиасы отвалятся и как их вернуть - не понятно.
А если вы про nginx, то мне тоже приходила в голову мысль набросать на js скриптик, который бы подменял пути в <form>, хотя Ваш вариант с ngx_http_sub_module понравился больше.
 
Последнее редактирование:
Назад
Верх