[Админам]

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

подобные проблемы:
http://vbsupport.ru/forum/showthread.php?t=41151
http://vbsupport.ru/forum/showthread.php?t=27860
http://vbsupport.ru/forum/showthread.php?t=27371

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

проблема проявилась после обновления файловика с версии 1.1.0 до 2.1.3 на форуме одного из клиентов
но не в хаке дело, у других клиентов все в порядке (на саппорте в том числе)
что удалось выяснить методом научного тыка...
если я удаляю (либо переименовываю, что в данном случае одно и то же) файл битфилдов продукта, при переходе к редактированию, сначала происходит перестроение битфилдов и потом редирект к собственно редактированию
это нормально, так и должно быть
естессно пропадают настройки этого продукта, файл которого удалили
но сейчас описание процесса без удаления/переименования
==
при редактировании группы, в форме есть скрытые поля, которые добавляются функцией construct_hidden_code(), среди них есть и добавление поля usergroupid

PHP Code:

construct_hidden_code('usergroupid', $vbulletin->GPC['usergroupid']); 


генерится такой хтмл

<input type="hidden" name="usergroupid" value="$usergroupid" />

ок, редактируем настройки прав
при нажатии кнопки "обновить", идет пост запрос
в пост запросе данные - массив usergroup и данные скрытого поля usergroupid
теперь самое интересное (дебаг)
если не удалять файл битфилда (наш случай - баг/косяк/глюк), то значение этого поля (usergroupid) всегда равно нулю (хотя в сорсе страницы я вижу правильное значение этого поля), соответственно вместо обновления данных, создается новая группа, с только что отредактированнными настройками
если удаляю файл битфилда, значение поля usergroupid нормальное, т.е. соотвествует ID группы, которую только что правил
перерыл файлы битфилдов от всех продуктов, несколько раз проверял свой файл, ошибок нет нигде
да и вобла ругалась бы матом, если бы в файле были ошибки, будь то синтаксис XML самого файла или ошибки в битовых полях

еще интересный момент
если удалить все файлы БФ других продуктов и оставить только вобловский и от файловика, то все нормально редактируется, но стоит вернуть файл БФ от любого из продуктов, как проблема возвращается
===

предполагаемая проблема: модуль Suhosin, который по каким то ведомым только ему причинам удаляет из запроса значение поля usergroupid
решение проблемы применительно к данному конкретному случаю
удалить модуль Suhosin с сервера и забыть как страшный сон
===

проверить, есть ли на сервере установленый модуль Suhosin, можно в админке, открыв информацию PHP Info
сделать поиск по странице по слову Suhosin

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

Originally Posted by kerk

удалить модуль Suhosin с сервера и забыть как страшный сон

Вообще suhosin-ов два - патч и модуль. в debian/ubuntu патч навсегда, а модуль еще можно удалить. вероятно многие дистрибутивы в конце концов перейдут на suhosin.
Не очень понял, что ты тут описал и как это воспроизвести, но проблемы фильтрации suhosin я решаю увеличиванием post_max_size. Просто увеличь с большим запасом.

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

Originally Posted by netwind

проблемы фильтрации suhosin я решаю увеличиванием post_max_size

почему же тогда он режет именно это поле?
там массив довольно объемный

Originally Posted by kerk

почему же тогда он режет именно это поле?
там массив довольно объемный

ну может быть это поле последнее по порядку ?

я пробовал переносить это поле в разные места (редактировал файл) - нифига
единственный костыль, который работал нормально *:
вместо

PHP Code:

construct_hidden_code('usergroupid', $vbulletin->GPC['usergroupid']); 


добавляем это поле в массив

PHP Code:

construct_hidden_code('usergroup[usergroupid]', $vbulletin->GPC['usergroupid']); 


и затем сразу после

PHP Code:

// ###################### Start insert / update #######################
if ($_POST['do'] == 'update')
{
    $vbulletin->input->clean_array_gpc('p', array(
        'usergroup' => TYPE_ARRAY,
        'ugid_base' => TYPE_INT,
    )); 


добавляем этот код

PHP Code:

if($vbulletin->GPC['usergroup']['usergroupid'] AND !$vbulletin->GPC['usergroupid'])
{
      $vbulletin->GPC['usergroupid'] = $vbulletin->GPC['usergroup']['usergroupid'];
      unset($vbulletin->GPC['usergroup']['usergroupid']);
} 


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

там много разных фильтров в suhosin. жаль что не удалось подробнее изучить какой из них сработал.

для меня suhosin - это один из тех "зеленых человечков", которых хочется убить =)
поэтому, обнаружив "источник зла", грохнул его не разбираясь в подробностях
может сукосин и несет какую то полезную нагрузку, незнаю, но мне кажется от него больше вреда, чем пользы