Coldfusion User Group Ukraine

Glassfish как application server для Сoldfusion

Достаточно много критики поступает в редакцию Adobe за использование во все стороны устаревшего сервера приложений JRun4. Вероятно в 10 версии Coldfusion будет использоваться другой сервер. Но необязательно ждать, уже сейчас можно облегчить себе жизнь. Например, поступить как описывает Пол Кукель (Paul Kukiel) в этом посте. Суть проста - установить сервер приложений Glassfish, и установить Coldfusion как WAR-приложение внутри "стеклорыбы". Кроме того, Railo тоже можно скачать как WAR-приложение и использовать вместе с Glassfish. Самое приятное, что настроив в Apache два виртуал-хоста, можно использовать Coldfusion и Railo вместе на одной машине - только различать их по имени хоста. При этом, связка GF+CF+Railo работает действительно быстро, субъективно, но я уверен, что точные тесты покажут ускорение объективно.

Заливка по FTP из Coldfusion Builder

Railo Tips: типи аргументів, відносні шляхи та згенеровані ключі

Працюючи над портуванням проекту під Railo стикаюся з різними особливостями роботи двигуна, котрі варто пам'ятати щоб не наступати на ці граблі надалі.

Спершу виникла проблема з nullable атрибутами в Transfer ORM. В моєму випадку NULL для поля з типом DATE зручно було використовувати для дати завершення строку дії рахунку. Для цього дефініція виглядала наступним чином:

<property name="expirationDate" type="date" column="exp_date" nullable="true" />

Тоді методи object.setExpirationDateNull() / object.getExpirationDateIsNull() давали потрібний результат.

Transfer зберігає NULL-дати в своєму особливому форматі (фактично, дата в далекому минулому), але при витягання NULL з бази все одно ColdFusion конвертував його в порожій рядок. Цей факт і став фатальним при передачі витягнутого значення сеттерові setExpirationDate(<date>).

Railo, на відміну від CF8, не бажає сприймати порожній рядок як коректну дату при передачі його аргументом функції.

Внаслідок цього довелося відмовитися від nullable атрибутів та трішки переробити спосіб відслідковування дат завершення строку.

UPDATE

Насправді, це виявилося проблемою коду, що взаємодіяв з Transfer. Бо несприйняття порожнього рядку є нормальним явищем для будь-якого CFML парсера.

Іншою проблемою стало використання наступного методу ініціалізації об'єкта:

variables.logBean = CreateObject("component", "model/LogBean").init( arguments.pageid, arguments.userid );

Такий відносний шлях не спрацював в Railo.

На щастя, динамічні мапінги в ньому працюють, тому я використав вже існуючий і переробив код наступним чином:

variables.logBean = CreateObject("component", "components.core.model.LogBean").init( arguments.pageid, arguments.userid );

Наостанок мене трохи розчарував той факт, що Railo не дістає останній доданий ключ в result запиту, зокрема для MySQL там не встановлюється GENERATED_KEY взагалі (додано 30.11.2009 -- виправлено!). В якості тимчасового рішення використав наступний спосіб:

<cflock name="#this.lockName#" type="exclusive" timeout="5">

    <!--- push bean into the db ---->
    <cfquery datasource="#variables.dsn#" name="qAddLogEvent" result="qResult">
        INSERT INTO #variables.tableLogCurrent#
            (id_page, id_user, log_type, log_message, log_detail, remote_ip, moment)
        VALUES
            (
             <cfqueryparam cfsqltype="cf_sql_integer" value="#logBean.getPageId()#" />,
             <cfqueryparam cfsqltype="cf_sql_integer" value="#logBean.getUserId()#" />,
             <cfqueryparam cfsqltype="cf_sql_char" value="#logBean.getLogType()#" />,
             <cfqueryparam cfsqltype="cf_sql_char" value="#logBean.getLogMessage()#" />,
             <cfqueryparam cfsqltype="cf_sql_char" value="#logBean.getLogDetail()#" />,
             <cfqueryparam cfsqltype="cf_sql_char" value="#logBean.getRemoteIp()#" />,
             <cfqueryparam cfsqltype="cf_sql_timestamp" value="#logBean.getMoment()#" />
            )
    </cfquery>

    <!--- this is a workaround for the engines not supporting GENERATED_KEY --->
    <cfif NOT StructKeyExists(qResult, "GENERATED_KEY")>

         <cfquery datasource="#variables.dsn#" name="qResult">
             SELECT LAST_INSERT_ID() AS GENERATED_KEY
         </cfquery>

    </cfif>

</cflock>

Хорошою ж новиною є те, що цей прикрий факт можна змінити. Для цього треба проголосувати у відповідному запитові Uservoice. Знаючи лояльність розробників я вірю, що потрібні зміни будуть доволі скоро.

Вектор Script Injection атаки

Марк Кругер (Mark Kruger) знову робить корисну справу: досліджує можливість проведення Script Injection атаки через завантаження (upload) шкідливого скрипта.

Він розглядає послідовність кроків для "обману" скрипта завантаження, котрий хоч і проводить перевірку даних, але має розповсюджену вразливість, на котру рідко звертають увагу: завантаження відразу відбувається в публічно доступну директорію. Завдяки затримкам між етапами обробки є можливість виконати шкідливий скрипт до того, як його буде видалено.

Також приводяться кілька порад (здавалося б, очевидних для досвідченого розробника) щодо покращення загальної безпеки ресурсів з можливістю завантаження файлів користувачами.

Про все це дещо докладніше в Script Injection Attack: Smoking Gun?

Найбільшою проблемою дослідження наслідків такої атаки є труднощі з ідентифікацією шкідливих скриптів, адже вони вже не існують пост-фактум. Особисто я використовую два обробники помилок 404 в Application.cfc: один слугує для запису помилок, перенапрямлених з веб-серверу (фейкова сторінка 404.cfm), інший -- для заптів до недозволених cfm-сторінок (дозволені зазвичай index.cfm та wsdl.cfm - для веб-сервісів). Це дає деяку інформацію у випадку спроб дослідження додатку через навмисні запити до неіснуючих сторінок.

Створення власної вбудованої функції в Railo

Що мені подобається в Railo, так це наявність зворотнього зв'язку його розробників зі спільнотою.

Вони постійно публікують інформацію про оновлення, надають приклади та обговорюють їх з CF-розробниками.

Цього разу розповіли про цікаву можливість: встановлення будь-якої UDF на рівні сервера, або віртуального хосту.

Coldfire - удобный дебаггер для Coldfusion

Coldfusion умеет выдавать debug информацию в специальном шаблоне, который добавляется внизу вызываемой страницы. Это удобно, доступна масса информации о выполняемом шаблоне. При этом вид страницы катастрофически страдает - три-четыре экрана текста после закрывающего тега <html> не придутся браузеру по душе. Решить эту проблему поможет плагин Coldfire. Он работает как дополнение Firefox, для его работы нужен установленный Firebug. Плагин состоит из двух частей - плагин (xpi) для Firefox и темплейт (coldfire.cfm) для Coldfusion.

План таков:

1. Скачиваем Firebug и устанавливаем, если это еще не сделано: http://getfirebug.com/

2. Скачиваем Coldfire: http://coldfire.riaforge.org/

3. Устанавливаем плагин coldfire.xpi для Firefox (проверено для Firefox 3.0.10, Firebug 1.3 и coldfire_v1.3.187.187.xpi)

4. Копируем coldfire.cfm в [CFROOT]/wwwroot/WEB-INF/debug/

5. В Coldfusion Administrator выбираем этот темплейт для отображения дебага (при этом сам дебаг должен быть включен, см. скриншот):

6. Сохраняем настройки, запускаем Firebug и пробуем выполнить какой нибудь CF шаблон на сервере. На закладке Coldfusion должна появится Debug информация. Добавляя нужные переменные в вывод, получаем требуемую информацию, не ломая дизайна сайта.