ExBB Community » » Установка и обновление » Не могу поставить форум на хостинг

Страниц (3): « 1 [2] 3 »
 

16. NordWest - 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. NordWest - 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. NordWest - 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. NordWest - 26 сентября 2013 — 07:00 - перейти к сообщению
Ну вот и прояснилось...
Другими словами в файлах с данными (в файлах, где в самом начале идёт <?die;?> ) ничего не меняем. По остальному коду можно по возможности тег <? заменить на <?php
Однако, вероятно, если у вас и так всё работает, то лучше ничего не трогать. Просто иметь ввиду, что такой нюанс может выплыть при перезде на другой хостинг (мало ли там какие настройки).
23. 1Bot - 26 сентября 2013 — 07:48 - перейти к сообщению
Чтобы разрешить использование short tags (т.е. <? вместо или вместе с <?php) необходимо в php.ini добавить|исправить следующую строку:
CODE:
short_open_tag=On
24. NordWest - 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. NordWest - 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. NordWest - 26 сентября 2013 — 15:51 - перейти к сообщению
Попробовал открыть в браузере у себя на форуме файл с данными и преспокойно увидел его содержимое. Я в шоке!!! Не понял А?!
Попробую применить ваши рекомнендации, но помоему это дыра в безопасности размером с кулак. И дело даже не в том, что такая возможность есть - плохо что скрипт об этом не предупреждает. Вот не возьмись мы про это рассуждать я бы так и сидел на *опе ровно. Однако
29. BON - 26 сентября 2013 — 16:26 - перейти к сообщению
NordWest пишет:
Попробовал открыть в браузере у себя на форуме файл с данными и преспокойно увидел его содержимое

какой файл с данными ? к примеру. и какие права стоят?
30. NordWest - 26 сентября 2013 — 16:29 - перейти к сообщению
Что-то мне подсказывает, что всё же проще защитить данные полными тегами и не морочить себе голову мудрёным конфигурированием php.ini.
(Добавление)
BON пишет:
какой файл с данными ?
Я пробовал открыть users.php и увидел весь список пользователей. Права стоят полные. Сейчас попробую подрезать.
(Добавление)
Поставил права 666 - пофиг, всё равно вижу.
(Добавление)
Поставил 660 - теперь не вижу, но будет ли при таких правах форум работать?
(Добавление)
Проверил - форум работает, но регаться не даёт.
CODE:
Could not write in the file data/users.php


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

Яндекс.Метрика   

Powered by ExBB
[Script Execution time: 0.0475]     [ ]