ExBB Community :: Версия для печати :: Не могу поставить форум на хостинг [2]

16. - 22 сентября 2013 — 09:17 - перейти к сообщению

Обновлял свой форум с ExBB FM 1.0 RC1.01 до версии ExBB FM 1.0 Final и столкнулся с неожиданной проблемой - сервер перестал отдавать страницы. Причем не показывал ошибок - просто говорил, что адреса по которому лежит форум не существует. Я бился целый вечер, и в конце концов решил проблему.

Как оказалось мой хост не любит устаревших тегов начала php кода
У меня в одном месте было <? а нужно строго <?php
Я прогнал поиск на предмет этого косяка по всему коду - нашел ещё три проблемных места.

И ещё. Если есть проблемы с запуском кода на сервере очень полезно в начало файла common.php добавить строку

CODE:

ini_set('display_errors', 'on');

После этого сервер перестаем молчать как партизан и вываливает информацию об ошибках.

17. CAB - 22 сентября 2013 — 17:10 - перейти к сообщению

NordWest, а в каких конкретно файлах не было php?

18. - 22 сентября 2013 — 17:35 - перейти к сообщению

Я у себя уже всё поправил - теперь не найти. Но сейчас по исходному дистрибутиву поищу...
(Добавление)
setmembers.php

CODE:

fwrite($fp,"<? die; ?>\n".$fm->input['wordarray']);

badwords.php

CODE:

<? die; ?>

skip_mails.php

CODE:

<? die(); ?> # Удалите этот файл, если это вам не нужно

19. CAB - 22 сентября 2013 — 21:25 - перейти к сообщению

Покопался у себя на форуме... Очень много файлов начинаются с

CODE:

<?die;?>

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

CODE:

<? die; ?>
<?phpdie;?>
<?php die; ?>

и ещё некоторые, приводит к тому, что содержимое файлов не читается. Поэтому решил пока не вносить исправления. Непонятная мне ситуация...

20. - 23 сентября 2013 — 06:12 - перейти к сообщению

Мне самому это всё не очень понятно.
Вероятно не всё так однозначно. Тут нужно внимательнее код посмотреть - вероятно вызовы php кода из ява скрипта должны обрамляться именно тегами <? ?>
а не <?php ?>
Попробую разобраться и отпишусь.
(Добавление)

CAB пишет:

<?phpdie;?>

Вот эта запись точно неверная...

21. 1Bot - 26 сентября 2013 — 05:47 - перейти к сообщению

CAB пишет:

Покопался у себя на форуме... Очень много файлов начинаются с

CODE:

<?die;?>

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

CODE:

<? die; ?>
<?phpdie;?>
<?php die; ?>

Попробую немного прояснить ситуацию: если хотите изменить файлы данных форума (не код, а именно данные), то необходимо и поменять соответствующие функции считывания function _Read($filename) и записи _Write этих данных, которые описаны в классе fm.
Если этого не сделать, а поменять данные "вручную", т.е. <?die;?> (строка, которая занимает 8 символов) на <?php die; ?> (строка, которая занимает 13 символов), то данные не могут быть корректно прочитаны.

Смотрите пример, в коде примера нужно заменить строки:
$filesize = ($filesize === 0) ? 1:$filesize-8; на строку $filesize = ($filesize === 0) ? 1:$filesize-13;
и fseek($fp, 8); на строку fseek($fp, 13);

22. - 26 сентября 2013 — 07:00 - перейти к сообщению

Ну вот и прояснилось...
Другими словами в файлах с данными (в файлах, где в самом начале идёт <?die;?> ) ничего не меняем. По остальному коду можно по возможности тег <? заменить на <?php
Однако, вероятно, если у вас и так всё работает, то лучше ничего не трогать. Просто иметь ввиду, что такой нюанс может выплыть при перезде на другой хостинг (мало ли там какие настройки).

23. 1Bot - 26 сентября 2013 — 07:48 - перейти к сообщению

Чтобы разрешить использование short tags (т.е. <? вместо или вместе с <?php) необходимо в php.ini добавить|исправить следующую строку:

CODE:

short_open_tag=On

24. - 26 сентября 2013 — 09:05 - перейти к сообщению

Не все хостинги разрешают напрямую что-либо менять в php.ini - у меня как раз такой случай. Улыбка

А если в код вставить такой код, интересно он отработает?

CODE:

ini_set('short_open_tag', 'on');

25. 1Bot - 26 сентября 2013 — 09:44 - перейти к сообщению

NordWest пишет:

Не все хостинги разрешают напрямую что-либо менять в php.ini - у меня как раз такой случай. Улыбка

А если в код вставить такой код, интересно он отработает?

CODE:

ini_set('short_open_tag', 'on');

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

26. - 26 сентября 2013 — 10:51 - перейти к сообщению

1Bot пишет:

Это не имеет смысла,

Всё, я запутался... Огорчение

1. Правильная настройка это когда короткие теги на сервере разрешены. Если их запретить, то при попытке непосредственного обращения к файлу с данными сервер проигнорирует команду die; и просто откроет файл в браузере, а это потенциальная дыра.
2. С другой стороны может сложиться такая ситуация, когда админины хоста запретили использование коротких тегов и никак это не поменять. Тогда имеет смысл переработать код функций _Read и _Write что бы и файлы с данными были закрыты полными тегами.

27. 1Bot - 26 сентября 2013 — 13:17 - перейти к сообщению

NordWest пишет:

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

Можно создать собственный файл php.ini и разместить его в папке вызываемого скрипта. Данная информация актуальна для серверов где PHP установлен как обработчик CGI (suPHP).
Если Вы решили положить php.ini где-то в public_html, то создайте файл .htaccess в корневой папке сайта ( например /home/user/public_html) или если файл существует, то только добавьте в любом месте (в начале или конце) в файл .htaccess директивы которые описаны ниже.

CODE:

<Files php.ini>
order allow,deny
deny from all
</Files>

эти директивы запрещают просмотра файла php.ini посторонними.

Примечание
При такой установке PHP в виде обработчика CGI, SuPHP, Вы не можете использовать в файле .htaccess следующие директивы : php_flag, php_admin_flag, php_value и прочих, которые изменяют какие-либо параметры PHP окружения это вызовет ошибку с кодом 500, Internal Server Error.

Внимание: собственный файл php.ini действителен только в пределах директории, в которой размещён, если не указана специальная опция, см. ниже.

CODE:

suPHP_ConfigPath /home/user/public_html

т.е. впишите эту строку в файл .htaccess перед кодом запрета просмотра файла php.ini.

P.S. Во всех папках с данными форума имеется файл .htaccess, который запрещает вызов любых скриптов из этих папок.

28. - 26 сентября 2013 — 15:51 - перейти к сообщению

Попробовал открыть в браузере у себя на форуме файл с данными и преспокойно увидел его содержимое. Я в шоке!!! Не понял

Попробую применить ваши рекомнендации, но помоему это дыра в безопасности размером с кулак. И дело даже не в том, что такая возможность есть - плохо что скрипт об этом не предупреждает. Вот не возьмись мы про это рассуждать я бы так и сидел на *опе ровно. Однако

29. BON - 26 сентября 2013 — 16:26 - перейти к сообщению

NordWest пишет:

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

какой файл с данными ? к примеру. и какие права стоят?

30. - 26 сентября 2013 — 16:29 - перейти к сообщению

Что-то мне подсказывает, что всё же проще защитить данные полными тегами и не морочить себе голову мудрёным конфигурированием php.ini.
(Добавление)

BON пишет:

какой файл с данными ?

Я пробовал открыть users.php и увидел весь список пользователей. Права стоят полные. Сейчас попробую подрезать.
(Добавление)
Поставил права 666 - пофиг, всё равно вижу.
(Добавление)
Поставил 660 - теперь не вижу, но будет ли при таких правах форум работать?
(Добавление)
Проверил - форум работает, но регаться не даёт.

CODE:

Could not write in the file data/users.php

Короче фигня это всё. Пойду я лучше код переписывать. Там изменений не много, а решение получится универсальное.