Как перенести файл configuration.php через defines.php Joomla 3.5 / У меня что то не работает? - Joomla 3.x: Общие вопросы

Как перенести файл configuration.php через defines.php Joomla 3.5 / У меня что то не работает

JPATH_CONFIGURATION путь измените

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

Нет никакого смысла переносить эти файлы.

Чего?

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

ну например пропишите точно также как JPATH_LIBRARIES, и положите configuration.php в папку libraries

Чего?

А того))

JFactory::getConfig();

Какая разница, где будет лежать файл конфигурации?

думаю 99% ботов не будут подключать апи Joomla, а обратятся напрямую к /configuration.php

думаю 99% ботов не будут подключать апи Joomla, а обратятся напрямую к /configuration.php

Ну а смысл, что они обратятся? Это же PHP файл, он нечитаем для мира, лишь исполняем.

dmitry_stas, я за пределами папки public_html создал папку conf/ru/ и туда положил файл.

Как мне прописать путь правильно?

Ну а смысл, что они обратятся? Это же PHP файл, он нечитаем для мира, лишь исполняем.

обратятся - я имею в виду include

dmitry_stas, я за пределами папки public_html создал папку conf/ru/ и туда положил файл.

а php имеет туда доступ, за пределы папки public_html? если за пределы - то надо писать абсолютный путь от корня сервера

обратятся - я имею в виду include

Тогда это не боты, а шеллы. А большинство шеллов (с которыми мне приходилось сталкиваться) - то есть абсолютно все, как раз подключает апи Joomla!

Тогда это не боты, а шеллы.

автоматический скрипт = робот = бот

А большинство шеллов (с которыми мне приходилось сталкиваться) - то есть абсолютно все, как раз подключает апи Joomla!

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

Школьник должен суметь распознать публичные свойства конфигурационного файла. Одним инклюдом к базе данных не подключишься. Проще переписать какой-нибудь скрипт Joomla! и обратиться к конфигу из этого файла.

а что там распознавать, если атака направлена на Joomla?
куда проще (и на самом деле надежнее) чем переписывать что то (учитывать разницу версий Joomla и другие вопросы, чтобы все было коректно), запускаться в контексте Joomla и обращаться к конфигу

Все именно так, как говорит dmitry_stas, меня пытались взламывать.

Ну почему проще?
Почти все шеллы легко определяют платформу, которую собираются атаковать, и для всех этих платформ у них имеются свои способы атаки. Если шелл создаёт экземляр класса JConfig, то ему уже заведомо известно, что это Joomla! То есть, эффективность переноса конфига в другую папку равна нулю. Кроме геморроя, связанного с совместимостью или обновлениями этот способ защиты от шеллов ничего не принесёт.

С обновлениями проблема будет, согласен.

Почти все шеллы легко определяют платформу, которую собираются атаковать, и для всех этих платформ у них имеются свои способы атаки. Если шелл создаёт экземляр класса JConfig, то ему уже заведомо известно, что это Joomla!

я об этом и говорю, он знает что это Joomla. и гораздо легче просто проинклудить файл, чем подключать апи.

Кроме геморроя, связанного с совместимостью или обновлениями

какого? никаких проблем не будет. defines.php легко переопределяется.

какого? никаких проблем не будет. defines.php легко переопределяется.

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

проинклудить файл

Дмитрий (Станислав?), я реально не видел ни одного шелла, который бы не изменял файлы ядра.

может стоит начать с обноления до 3.6.x а потом уже устраивать не пойми что с движком. Обновления + компонент банальной защиты типа RSfirewall + мастер пароль для админки + ни какого вареза + постоянные проверки и 3\4 ботов вам ничего не сделают. Остальная четверть уже пост фактум. Ну а если вам ломают предметно то тут вас и папа римский не спасет. Если дошли до конфига то уже как-то побую куда вы его уберите.

4 совета ТС
1. Успокойтесь.
2. Если серьезно настоялись изучать вопрос безопасности то лучше создайте один топик с просьбой подсказать хорошую литературу.
3. Выделите много много времени прочитайте все что вам предложат и это даст вам общее представления.
4. Не возможно создавать (не могу подобрать слово) защиту не знаю нападения. Этот вопрос вам придется изучать самим, тут вам ни кто не поможет.
Итого Успокойтесь, запаситесь терпением, желанием и временем и может через годик - два(тут от человека зависит) вы будете понимать основы. А если у вас все горит наймите специалиста.

может стоит начать с обноления до 3.6.x а потом уже устраивать не пойми что с движком. Обновления + компонент банальной защиты типа RSfirewall + мастер пароль для админки + ни какого вареза + постоянные проверки и 3\4 ботов вам ничего не сделают. Остальная четверть уже пост фактум.

Взломают как два пальца, если надо.... )) Особенно если хостер - шаред. Не надо уповать на компоненты защиты.

Хостер вообще кого угодно может взломать.

Взломают как два пальца, если надо.... )) Особенно если хостер - шаред. Не надо уповать на компоненты защиты.

НУ поэтому и 3\4. Если надо то тут тебя уже ни что не спасет, даже сейф топор и автомат. А уповать не стоит, но лишним не будет, просто многие даже не читают что эти компоненты делают и думаю что поставил и забыл.
А вот про норм хостинг я как-то не подумал ибо само собой разумеется, ну и то что за сайтом надо следит, а не проверять раз пол года.

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

на самом деле я бы тоже клиентам не стал профита действительно совсем чуть чуть. но ТС не клиентам, себе. поэтому почему бы не побаловаться

Дмитрий (Станислав?)

первое стас - то от фамилии

я реально не видел ни одного шелла, который бы не изменял файлы ядра.

правда? а я много раз. у ТС кстати судя по всему именно такой был, просто прямое обращение к файлу было

Взломают как два пальца, если надо.... )) Особенно если хостер - шаред. Не надо уповать на компоненты защиты.

плацебо аля RSFirewall вообще надо запретить обсуждать

Хостер вообще кого угодно может взломать.

так можно далеко зайти теория мирового заговора? еще бы оно было надо вашему хостеру...

плацебо аля RSFirewall вообще надо запретить обсуждать

Я думаю надо просто людям объяснить, ну тем которые читать не умеют что он делает. Как тулс он удобен, блок по IP есть, проверка файлов ядра на изменения тоже, мастер пасс для админки, ну и запрет изменения супер админа. Не панацея, но время экономит.

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