Интересная логика кода

[proba 57]

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

Хотел бы в данном сообщении рассмотреть часть кода из файла profile.php (из папки modules), оформление упростил (пробелы, переносы строк, и не важные действия кода убрал). А теперь по порядку, пусть приметивно буду описывать, но Вы думаю сможете понять меня.

...

//условие выполняется, если мы т.с. пришли сюда после нажатия кнопки Отправить

if( $allow_userinfo and $doaction == "adduserinfo" ) {

...

//$id = чей профиль мы пожелали изменить (свой, чужой)

$id = intval($_POST['id']);

//если мы не авторизованы или ... или не передали $id мы дальше не пройдем

if( !$is_logged OR $_POST['dle_allow_hash'] == "" OR $_POST['dle_allow_hash'] != $dle_login_hash OR !$id) {

  die( "Hacking attempt! User ID not valid" );

}

//если мы пожелали изменить чужой профиль и мы не администратор мы не пройдем дальше

//т.е. может пройти либо по своему, либо админ - тебе всегда можно

if ( $member_id['user_id'] != $id AND $member_id['user_group'] != 1 ) { die( "Hacking attempt!" ); }

//здесь мы будем либо это наш профиль (как любой авторизованный пользователь сайта), либо под авторизованным администратором


//получаем данные профиля, который мы хочем изменить: админ - любого, остальные только свои

$row = $db->super_query( "SELECT * FROM " . USERPREFIX . "_users WHERE user_id = '{$id}'" );


//вот и первые странности

//если мы не авторизованны или полученные данные из БД не от нашего профиля, либо мы не админ

//но как мы можем быть не авторизованны, если данное условие проверялось выше?!

//вторая часть условия пересекается с предыдущим условием - ну даладно с ним

if( !$is_logged or !($member_id['user_id'] == $row['user_id'] or $member_id['user_group'] == 1) ) {

  $stop = $lang['news_err_13'];

} else {

  //если все нормально, то мы уже здесь

  ...

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

  $password1 = $_POST['password1'];

  ...

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

  $altpass = md5( $_POST['altpass'] );

  ...

  //если мы указывали новый пароль

  if( strlen( $password1 ) > 0 ) {

   $altpass = md5( $altpass );

   //если мы указывали не наш действующий пароль

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

   //мы должны указать свой пароль, под которым авторизовались: всем - только свой, админу

   //изменяющему (свой или чужой) тоже свой! может быть и ладно, пропустим

   if( $altpass != $member_id['password'] ) { $stop .= $lang['news_err_17']; }

   if( $password1 != $password2 ) { $stop .= $lang['news_err_18']; }

   if( strlen( $password1 ) < 6 ) { $stop .= $lang['news_err_19']; }

   //если мы указав новый пароль изменяем свой профиль (не чужой) и у нас есть право "управлять"

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

   //хорошо, админу - ограничили, меняй свой пароль только в админпанели, но...

   //другие группы имея такое разрешение и не имея доступа к админпанели не смогут изменить свой пароль.

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

   //пользователями. зачем допускается давать такое право другим группам в админпанели?

   if ($member_id['user_id'] == $row['user_id'] AND $user_group[$member_id['user_group']]['admin_editusers']) {

    $stop .= $lang['news_err_42'];

   }

  }

  ...

  //если мы указывали новый пароль, полученные данные из БД от нашего профиля и мы имеем право "управлять"

  //пользователями... снова ограничили админа - меняй е-майл только в админпанели.

  //условие подобно предыдущему, и если мы указывали новый пароль и е-майл, то таких сообщений должно показаться 2.

  //конечно, их можно объединить в один, но вопросы по праву "управлять" пользователями все равно остались!

  if ($member_id['user_id'] == $row['user_id'] AND $email != $member_id['email'] AND $user_group[$member_id['user_group']]['admin_editusers']) {

   $stop .= $lang['news_err_42'];

  }

  //если указанный новый е-майл не соответствует нашему действующему е-майлу...

  //если так, то идет проверка, а не относится ли новый е-майл к тем, что относятся к "спамерским".

  //но почему новый е-майл проверяется с е-майлом кто изменяет профиль, а не с тем, чьи данные хотят изменить?

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

  if ( $email != $member_id['email'] ) {

  ...

  }

  //здесь условие рассматривать особо нечего, только почему-то странно! проверяется, нет ли права "управлять"

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

  //права "управлять" пользователями - отправится письмо. с другой стороны, админ не имея права "управлять" выглядит

  //абсурдом, т.к. зачем его пропускать с преимуществом в самом начале?! админ изменяя кому-то е-майл, письмо не

  //отправиться - пользователь не уведомлён получается. так же не уведомлены и те, у кого право "управлять" имеется.

  if ($config['registration_type'] AND $email != $row['email'] AND !$user_group[$member_id['user_group']]['admin_editusers'] ) $send_mail_log = true; else $send_mail_log = false;

  //почему здесь сравниваются данные с настройками изменяющего данные, а не с теми настройками чьи берутся из БД?

  //ведь если мы как админ правим чьи-то данные, у нас возможно установленные данные для группы будут другими!

  if( intval( $user_group[$member_id['user_group']]['max_info'] ) > 0 and dle_strlen( $info, $config['charset'] ) > $user_group[$member_id['user_group']]['max_info'] ) {

   $stop .= $lang['news_err_22'];

  }

  //здесь те же вопросы, что и в предыдущем условии.

  if( intval( $user_group[$member_id['user_group']]['max_signature'] ) > 0 and dle_strlen( $signature, $config['charset'] ) > $user_group[$member_id['user_group']]['max_signature'] ) {

   $stop .= $lang['not_allowed_sig'];

  }

  ...

}

if( $stop ) {

  msgbox( $lang['all_err_1'], "<ul>".$stop."</ul>" );

} else {

...

Вопросы изложены в приведенной части кода.

[celsoft 6 094]

//если мы указав новый пароль изменяем свой профиль (не чужой) и у нас есть право "управлять"

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

//хорошо, админу - ограничили, меняй свой пароль только в админпанели, но...

//другие группы имея такое разрешение и не имея доступа к админпанели не смогут изменить свой пароль.

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

//пользователями. зачем допускается давать такое право другим группам в админпанели?

Возможность редактирования пользователей, это исключительная возможность админпанели, даже редактирование на сайте это действие выполняет админпанель. И абсурдностью в данном случае является включение этой настройки и отключение доступа в админпанель. Что собственно взаимоисключает эти настройки. Поэтому эта настройка находится во вкладке "Админпанель", и включение доступа к админпанели там делается в первую очередь, а потом включается что собственно разрешено делать в админпанели.

//здесь условие рассматривать особо нечего, только почему-то странно! проверяется, нет ли права "управлять"

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

//права "управлять" пользователями - отправится письмо. с другой стороны, админ не имея права "управлять" выглядит

//абсурдом, т.к. зачем его пропускать с преимуществом в самом начале?! админ изменяя кому-то е-майл, письмо не

//отправиться - пользователь не уведомлён получается. так же не уведомлены и те, у кого право "управлять" имеется.

Это проверка в случае если включена расширенная авторизация, т.е. требуется обязательное подтверждение E-mail, а не уведомление. Когда меняет администратор адрес, ему адрес подтвержать по E-mail не нужно.

//почему здесь сравниваются данные с настройками изменяющего данные, а не с теми настройками чьи берутся из БД?

//ведь если мы как админ правим чьи-то данные, у нас возможно установленные данные для группы будут другими!

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

[proba 57]

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

 

В функции check_category() файла functions.php есть такая строка:

$cats = str_replace(" ", "", $cats );

но почему-то нет подобной строки в подобных функциях, например, в функциях check_group() или check_page() файла templates.class.php.
Подразумевается, что при использовании одних тегов могут по каким-то причинам указать пробелы, при использовании других - нет?

 

При выявлении (если так можно выразится) наличия какого-нибудь тега, применяется то strpos(), то stripos(), например для тега custom в файлах main.php и templates.class.php. Выходит, что в одних случаях тег допускается использовать только в нижнем регистре, в другом - "как пожелаешь"? И такая неопределённость для тегов кругом.

 

В файле init.php имеются строки:

if( !isset ( $do ) AND isset ($_REQUEST['do']) ) $do = totranslit ( $_REQUEST['do'] ); elseif(isset ( $do )) $do = totranslit ( $do ); else $do = '';
if( !isset ( $subaction ) AND isset ($_REQUEST['subaction']) ) $subaction = totranslit ($_REQUEST['subaction']); elseif(isset($subaction)) $subaction = totranslit($subaction); else $subaction = '';

Интересует, когда выполнятся в них условия

elseif(isset ( $do ))

и

elseif(isset($subaction))

Ведь выше этих строк переменные do и subaction не определяются. Или это на случай register_globals?

 

В функции load_template() файла templates.class.php быть может строку

if ($file_path AND $file_path != ".") $tpl_name = $file_path."/".$tpl_name;

стоит поставить перед строкой

if ($type != "tpl") {

Аналогично и в функции sub_load_template().

[celsoft 6 094]

Подразумевается, что при использовании одних тегов могут по каким-то причинам указать пробелы, при использовании других - нет?

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

 

Ведь выше этих строк переменные do и subaction не определяются. Или это на случай register_globals?

Да, либо сторонних модулей.

 

[proba 57]

в функции custom_print() файла functions.php при обработке id имеется строка:

$where_id[] = "id >= '" . intval($value[0]) . "' AND id <= '".intval($value[1])."'";

наверное правильнее нужны тут скобки и она должна быть такой:

$where_id[] = "(id >= '" . intval($value[0]) . "' AND id <= '".intval($value[1])."')";

в файле rssinform.php имеется такая часть кода:

        $buffer = dle_cache( "informer_" . $value['id'], $config['skin'] );

        if ( $buffer !== false) {

            $file_date = @filemtime( ENGINE_DIR.'/cache/informer_'.$value['id'].'_'.md5(totranslit($config['skin'])).'.tmp' );

            if ( $file_date ) {

                if (date ( "d-H", $file_date ) != date ( "d-H" )) {

                    $buffer = false;
                    @unlink( ENGINE_DIR.'/cache/informer_'.$value['id'].'_'.md5(totranslit($config['skin'])).'.tmp' );

                }

            }

        }

и здесь название шаблона приводится в нижний регистр после фун-ии totranslit(), хотя через функцию create_cache() проходит в оригинале. может здесь функция totranslit() лишняя?!

 

в этом же файле есть ниже строка:

if ($info['filename'] == "spoiler-plus" OR $info['filename'] == "spoiler-plus" ) continue;

в чём подвох?

[celsoft 6 094]

и здесь название шаблона приводится в нижний регистр после фун-ии totranslit(), хотя через функцию create_cache() проходит в оригинале. может здесь функция totranslit() лишняя?!

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

 

в этом же файле есть ниже строка:

if ($info['filename'] == "spoiler-plus" OR $info['filename'] == "spoiler-plus" ) continue;

в чём подвох?

Это как раз таки нужна вещь. Когда источником потока служат сайты на DLE, чтобы не брать картинки из спойлеров. 

[proba 57]

Это как раз таки нужна вещь. Когда источником потока служат сайты на DLE, чтобы не брать картинки из спойлеров. 

Но оба условия совершенно одинаковые. Может один ключ массива info должен быть другим?

[celsoft 6 094]

А все понял, не обратил внимания. Нет там не ключ должен быть другим, а условие.

[proba 57]

А все понял, не обратил внимания. Нет там не ключ должен быть другим, а условие.

в движке имеются ещё несколько файлов, где встречаются такие же условия.

 

в файле calendar.php имеются такие строки:

$sql = "";

и

if( $sql != "" ) { ... }

первая строка в принципе не нужна, т.к. ниже переменная sql в любом случае определяется, а строка с проверкой на непустое значение (и закрывающая фигурная скобка условие) из-за того, что выше переменная sql определена - строкой для запроса к БД.

 

имеется ещё такая строка:

$month = totranslit($month, true, false);

при нынешнем определении переменной month (например, как в init.php) эта строка вроде как теряет актуальность... или нет?

 

при выборке из БД для предыдущих месяцев учитываются все новости  (и находящиеся на модерации), хотя для текущего (и последующих) месяца идёт проверка - только опубликованые. разве те, что на модерации стоит учитывать?

всё что выше касается и файла calendar.php в ajax

 

в двух файлах calendar.php при формировании календаря отличие одного от другого в обрамлении div'ом и кэшем. что если кэширование добавить в ajax'овый файл, в кэш не отправлять обрамление div'ом, а добавлять его только к tpl->result?

 

в inc/files.php имеются строки:

$allowed_extensions = array ("gif", "jpg", "png", "jpe", "jpeg" );

и чуть ниже

$allowed_extensions = array ("gif", "jpg", "png" );

одна строка однако лишняя...

да и вообще, allowed_extensions в движке странно себя ведёт, например в файлах register.php и profile.php.

[celsoft 6 094]

да и вообще, allowed_extensions в движке странно себя ведёт, например в файлах register.php и profile.php.

Что значит странно? 

при выборке из БД для предыдущих месяцев учитываются все новости  (и находящиеся на модерации), хотя для текущего (и последующих) месяца идёт проверка - только опубликованые. разве те, что на модерации стоит учитывать?

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

в двух файлах calendar.php при формировании календаря отличие одного от другого в обрамлении div'ом и кэшем. что если кэширование добавить в ajax'овый файл, в кэш не отправлять обрамление div'ом, а добавлять его только к tpl->result?

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

[proba 57]

Что значит странно? 

В файле profile.php в переменной присутствуют расширения jpe и  jpeg, в register.php они отсутствуют, хотя в обоих файлах идёт речь о аватарке. В social.php вроде тоже речь об аватарке, и тоже отсутствуют эти расширения.

В файле ajax/upload.php в переменной внесены все 5 расширений, хотя далее в upload.class.php для класса FileUploader только 4.

[proba 57]

В файле ajax/pm.php имеется строка:

if( ! @is_dir( ROOT_DIR . '/templates/' . $_REQUEST['skin'] ) or $_REQUEST['skin'] == "" ) {

здесь условия напрашиваются на перестановку их местами.

 

В файле ajax/poll.php "фильтрацию" и прохождение условий проходит ключ vote_skin массива _REQUEST, а на подключение языкового файла используется ключ skin.

[celsoft 6 094]

здесь условия напрашиваются на перестановку их местами.

Нет, т.к. скрипт в нормальной своей работе этот параметр всегда передает.

 

 В файле ajax/poll.php "фильтрацию" и прохождение условий проходит ключ vote_skin массива _REQUEST, а на подключение языкового файла используется ключ skin.

И что? 

[proba 57]

скрипт в нормальной своей работе этот параметр всегда передает.

Передаёт и пусть передаёт. Вступил с пустым значением у "skin".

И что? 

В ajax/poll.php передаются news_id, action, answer, vote_skin. И среди передаваемых параметров нет параметра skin, с помощью которого происходит попытка подключить website.lng.

[proba 57]

В файле sitelogin.php строку:

$member_id = array ();

думаю надо поставить после условия с запросом на внесение данных в "_admin_logs". Это там, где через куки проходит авторизация. Массив member_id обнуляется, и после по данным этого массива проверяются условия на выполнение запроса к БД.

 

В этом же файле имеется строка:

$_COOKIE['dle_hash'] = $hash;

Это в том месте, где идёт проверка данных переданных через форму. Но эта строка ни какой роли не играет.

 

В нескольких файлах встречается строка:

set_cookie( "dle_name", "", 0 );

Но чтобы устанавливалась кука - не нашел. Она ещё актуальна?

[proba 57]

В userfields.php имеется строка:

msg("error", $lang['xfield_error'], "$lang[xfield_err_1] \"".ENGINE_DIR."/data/xprofile.txt\", $lang[xfield_err_1]");

наверное подразумевалась такая реализация:

msg("error", $lang['xfield_error'], "$lang[xfield_err_1] \"".ENGINE_DIR."/data/xprofile.txt\", $lang[xfield_err_2]");

 

[proba 57]

В этом же файле:

$checked = ($editedxfield[5] ? " checked" : "");

переменная не используется вроде как. Может и ошибаюсь.

Имеется строка:

<input style="width:100%;max-width: 200px;" type="text" name="editedxfield[0]" value="<?php echo $editedxfield[0];?>" /> <i class="icon-warning-sign"></i> <?php echo $lang['xf_lat']; ?></span>

Нет открывающего тега span, либо закрывающий тег лишний. Такая же картина с тегом имеется ещё в /inc/static.php и /inc/xfields.php.

В строке

<select class="uniform" name="editedxfield[3]" id="type" onchange="onTypeChange(this.value)" />

слэш не нужен.

[celsoft 6 094]

proba,

 

Принято. Будет исправлено. 

[proba 57]

Забыл ещё указать строку из userfields.php

msg("options", $lang['xfield_err_6'], "$lang[xfield_err_6]<br /><br /><input onclick=\"document.location='?mod=userfields&xfieldsaction=configure&xfieldsindex={$xfieldsindex}&xfieldssubaction=delete2&user_hash={$dle_login_hash}'\" type=\"button\" class=\"btn btn-green\" value=\"{$lang['opt_sys_yes']}\">&nbsp;&nbsp;<input onclick=\"document.location='?mod=userfields&xfieldsaction=configure'\" type=\"button\" class=\"btn btn-red\" value=\"{$lang['opt_sys_no']}\">");

В первом lang[] наверное должен быть указан p_confirm

[proba 57]

В xfields.php строка

<textarea style="width:100%;max-width: 350px; height: 100px;" name="editedxfield[4_select]"><?php if ($editedxfield[4]{0} == "\r") $editedxfield[4] = "\n".$editedxfield[4]; echo ($editedxfield[3] == "select") ? $editedxfield[4] : "";?></textarea><br><?php echo $lang['xfield_xfsel']; ?></td>

в ней закрывающий тег td остался.

[proba 57]

Добрый день! Файл /modules/pm.php. В зависимости от значения в config['allow_comments_wysiwyg'], как понимаю, либо могут содержаться некоторые теги (без атрибутов) в сообщении, либо вырезаться полностью. Но!

 

При значении = 0, во входящем _POST['comments'], пройдя через функцию decode() в parse.class.php, все < преобразуются в их html сущности и filterTags() не вырезает уже теги.

 

При значении = 1, во входящем _POST['comments'] ещё по приходу в index.php, уже все < преобразованы в их html сущности и та же картина с filterTags().

 

При значении = 2, картина схожа со значением = 1, только уже все < и > преобразованы в их html сущности, и идёт обрамление тегом P и та же картина с filterTags().

 

Если подсунуть в _POST['comments'] "оригинальную" строку, например, были теги DIV, SPAN, A с атрибутами, то он обрабатывался filterTags() в такой вид:

<div />

хотя, думаю должен быть без слэша + после такого div остались теги SPAN и A с атрибутами, атрибуты не вырезались.

Возникают вопросы. Но хочется узнать на один. При значении config['allow_comments_wysiwyg'] > 0 символы < и > где обрабатываются в html сущности до прихода в index.php?

[celsoft 6 094]

При значении config['allow_comments_wysiwyg'] > 0 символы < и > где обрабатываются в html сущности до прихода в index.php?

Нигде.  index.php это собственно первый файл работы скрипта, и если текст пришел как то обработанным в него, то это уже сделал не скрипт DLE, а сервер, еще до запуска скриптов. Такое бывает когда на сервере стоят предварительные фильтры безопасности, которые предварительно фильтруют контент.

[proba 57]

На сайте редактора TinyMCE в демо попробовал ту же строку, картина такая же. Обработка в сущности < и > и обрамление тегом p идёт редактором.

Такое бывает когда на сервере стоят предварительные фильтры безопасности, которые предварительно фильтруют контент.

Если фильтры на сайте, то тогда при любом значении config['allow_comments_wysiwyg'] фильтрация шла бы, а так, идёт только когда  config['allow_comments_wysiwyg'] > 0

[celsoft 6 094]

Подождите, я не очень понял того что вы описываете, речь идет о < и > не в виде HTML тегов, а просто в виде символов, при использовании визуальных редакторов? Если да, то делает это браузер, потому как он формирует HTML код в момент визуального редактирования, и передает его редакторам, а те в свою очередь скрипту на сервер. Это можно увидеть открыв исходный код в редакторе, еще до его отправки на сервер, визуальный редактор работает в браузере а не на сервере.

Изменено 6 октября 2015 пользователем celsoft

[proba 57]

Попробую объясниться по другому:

Указав, к примеру, в "сообщении" ПМ (pm.php) такую строку:

qwerty<tr class="bg"><td background="img.gif" bgcolor="#2170ad"><div style="background-image: url(javascript:alert())">&nbsp;&nbsp;<span class="text2"><a href="#" style="color:#FFFFFF">ссылка</a></span></td></tr>

при config['allow_comments_wysiwyg'] = 0 на входе index.php в _POST['comments'] содержится строка:

qwerty<tr class="bg"><td background="img.gif" bgcolor="#2170ad"><div style="background-image: url(javascript:alert())">&nbsp;&nbsp;<span class="text2"><a href="#" style="color:#FFFFFF">ссылка</a></span></td></tr>

т.е. вроде как оригинал. дальше... при config['allow_comments_wysiwyg'] = 1 на входе index.php в _POST['comments'] содержится строка:

qwerty<tr class="bg"><td background="img.gif" bgcolor="#2170ad"><div style="background-image: url(javascript:alert())">  <span class="text2"><a href="#" style="color:#FFFFFF">ссылка</a></span></td></tr>

здесь уже < в виде html сущности. дальше... при config['allow_comments_wysiwyg'] = 2 на входе index.php в _POST['comments'] содержится строка:

<p>qwerty&lt;tr class="bg"&gt;&lt;td background="img.gif" bgcolor="#2170ad"&gt;&lt;div style="background-image: url(javascript:alert())"&gt;&amp;nbsp;&amp;nbsp;&lt;span class="text2"&gt;&lt;a href="#" style="color:#FFFFFF"&gt;ссылка&lt;/a&gt;&lt;/span&gt;&lt;/td&gt;&lt;/tr&gt;</p>

здесь уже < и > в виде html сужности + добавился тег p.

Обработка _POST['comments'] в parse.class.php проходит через функцию decode(), где (для 1-го случая) так же < и > преобразовываются в html сущности. После, через фун-ию remove() должна проходить фильтрация фун-ией filterTags(), но в ней первоначально ищется <, а его _POST['comments'] нет (есть для тега Р, но он разрешённый) и обрезка тегов в _POST['comments'] не производится.

Но, если подсунуть оригинальную строку в фун-ию filterTags(), например, при config['allow_comments_wysiwyg'] > 0, то обработается до такого:

qwerty<div />&nbsp;&nbsp;<span class="text2"><a href="#" style="color:#FFFFFF">ссылка</a></span>

Тег DIV кривой получается.