Комментарии пользователя «antonkuzmin»

0
Смешно. Дрова тоже будете на кабриолете возить?
avatar

antonkuzmin

  • 11 апреля 2012, 09:15
-1
ИМХО, такую штуку на MODX нет смысла делать.
Больше подойдет Друпал, Битрикс, или фреймворк какой-либо.
avatar

antonkuzmin

  • 10 апреля 2012, 17:11
0
Впечатлила некая рекурсия статьи, аккурат на втором заголовке «Вызов плагинов в коде» :)
avatar

antonkuzmin

  • 26 марта 2012, 14:15
0
закомментируйте все сниппеты по отдельности, чтобы понять по сколько запросов в среднем на какой сниппет приходится.
скорее всего дело действительно в шаблоне комментария Jot, а точнее в использовании в нем phx-сниппетов.
avatar

antonkuzmin

  • 29 февраля 2012, 16:32
0
Еще надо установить права на вновь создаваемые файлы в настройках и проставить права на запись в папку кеша, картинок и т.д.
avatar

antonkuzmin

  • 28 февраля 2012, 14:53
0
Насчет XML — CommerceML запаритесь разбирать, а вот обмен через csv — легко, как впрочем и в любой cms )
avatar

antonkuzmin

  • 28 февраля 2012, 09:30
0
В случае такой специфической задачи думаю можно и отключить friendly_urls — все равно если алиасы будут транслитерироваться из ФИО — это будет мешанина :)
avatar

antonkuzmin

  • 27 февраля 2012, 18:17
+1
Без комментариев =)
avatar

antonkuzmin

  • 27 февраля 2012, 18:13
+1
Синий и красный текст в контенте — очень плохо.
Кнопки навигации родом из 2006 года.
avatar

antonkuzmin

  • 27 февраля 2012, 15:54
0
1. Нужно указать в параметрах у WebloginPE присвоение группы пользователям (см. комментарий sazanof)
2. Можно пропатчить eForm (http://community.modx-cms.ru/blog/fast-solution/2477.html), написать сниппет типа [[getph?ph=`user.fullname`]], который будет возвращать содержимое установленного плейсхолдера и воткнуть его в шаблон eForm. Либо использовать событие eformOnBeforeFormParse / eFormOnBeforeFormMerge.
avatar

antonkuzmin

  • 24 февраля 2012, 14:57
0
Вообще я так и не смог подобрать связку сниппет+формат POST-запросов, чтобы заставить MODx вывести и обработать произвольный тег. Может к этому восприимчево только какое-то уникальное сочетание сниппетов?
avatar

antonkuzmin

  • 22 февраля 2012, 11:47
0
Интересное примечание в UPD3: каким образом вы пришли к заключению, что злоумышленник проник, используя именно эту уязвимость? Хотелось бы увидеть пример POST/GET-запроса, результатом которого оказалось выполнение произвольного PHP-кода именно на вашем сайте. Кстати такие подозрительные запросы легко можно отследить в логах апача.
avatar

antonkuzmin

  • 21 февраля 2012, 16:05
+1
Да, это появилось после очередного обновления Оперы, и меня просто дико выводит из себя :(
avatar

antonkuzmin

  • 21 февраля 2012, 15:23
+2
Насколько я понял, речь идет про MODx Evo.
Для себя я эту проблему давно решил в своей сборке.
В конце файла manager/media/calendar/datepicker.js нужно закомментировать условие, касающееся браузера Опера вот так:
/* Remove the calendar from the page */
    remove: function(dp){
        dp.active = false;
/*        if (window.opera) dp.container.empty();
        else */if (dp.container) dp.container.remove();
        dp.calendar = false;
        dp.container = false;
        $$('select.dp_hide').removeClass('dp_hide');
    }

По этому коду во-первых видно, что разработчики позаботились об Опере, а во-вторых очевидно, что это решение перестало работать в новых версиях, и его надо просто убрать.
Кстати баг-репорт об этом вместе с решением я отправил еще год назад, но никаких ответов об этом не получил. :(

avatar

antonkuzmin

  • 21 февраля 2012, 15:22
+5
Без паники, внимательней читаем анонс:
MODX Evolution had been sanitizing global GPC (GET/POST/Cookie or Request) variables in a way that allowed any Snippet within MODX that echoed user input (i.e. a website form field) from the GPC variables back to the output (for display) to inadvertently execute the MODX tags provided in the input field.
*Remote script execution requires specific configurations of add-ons included in the core.


То есть, уязвимость заключается в возможности выполнения некоторых тегов шаблонизатора MODx, посылая их через GET/POST.

Для возникновения описанной уязвимости требуется:
1) наличие сниппета, который принимает во входных параметрах PHP-код (и в дальнейшем EVAL-и его)
2) сниппет, который напрямую без обработки выводит содержимое какого-либо GET/POST-параметра (не параметра сниппета!). eForm я попроверял, вроде бы он фильтрует вывод.

В противном случае максимум, что возможно — запустить на выполнение произвольный сниппет с произвольными параметрами, что тоже не очень-то хорошо (напр. можно просканировать структуру сайта, увидеть неопубликованные страницы и т.д.)
avatar

antonkuzmin

  • 21 февраля 2012, 15:16
0
Я бы предпочел бесплатный free.timeweb.ru
По крайней мере там понятно, на чем они деньги зарабатывают )
Из минусов — на один аккаунт можно разместить только один сайт, и домен только третьего уровня.
avatar

antonkuzmin

  • 16 февраля 2012, 22:16
-3
Я бы назвал Revo веб-фреймворком со вшитой в него админкой, в то время как Evo — CMS/CMF.
avatar

antonkuzmin

  • 15 февраля 2012, 17:02
0
Именно так сделано в админке PimCore (на Zend Framework + ExtJS). Очень удобно и очень быстро работает, в отличие от Revo — все происходит через ajax — страница в процессе работы не перезагружается вообще!
avatar

antonkuzmin

  • 15 февраля 2012, 16:59
0
chec_mesto, info_pearent, worc_session — убили )))
Думаю, если этот код переписать по-нормальному, он сократится в пару раз )
avatar

antonkuzmin

  • 26 января 2012, 12:56