Построение XML-порталов на основе Cocoon

Введение

В 1998 году Stefano Mazzocchi, окончательно разочаровавшись в ограниченных возможностях HTML в области отделения контента от представления, инициировал разработку Apache Cocoon. Текущее состояние проекта подробно описано им статье, опубликованной на сайте XML.com.

Изначально Cocoon разрабатывался как система публикации на основе XML-XSL. Но мы убеждены, что благодаря расширяемой архитектуре за счет добавления различных компонент Cocoon может использоваться в значительно большем диапазоне приложений. Примерно в одно время с тем, когда мы познакомились с Cocoon, мы искали доступные коммерческие портальные решения для нескольких заказчиков. Порталы, используемые во многих коммерческих системах, имеют различные требования. Исходя из этих требований, мы пришли к идее расширения Cocoon компонентами аутентификации и портала, получив таким образом возможность использовать в своем решении основные преимущества Cocoon как платформы.

Новые компоненты изначально были разработаны как часть коммерческого предложения. Так, в середине 2001 года мы установили первый портал на основе Cocoon в одном финансовом учреждении в Германии. Однако, в начале 2002 года мы передали наши наработки проекту Cocoon. В их числе были компоненты и средства для аутентификации (под названием "sunRise") и для построения порталов (под названием "sunSpot"). Каждый из этих элементов можно использовать отдельно от другого. Например, средства аутентификации можно использовать для защиты некоторых ресурсов на сервере.

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

Аутентификация

Аутентификация пользователя является одним из центральных аспектов любого современного связующего приложения. После того как пользователь вошел в систему, он получает доступ к предварительно сконфигурированным ресурсам в соответствии с его user-id или ролью.

Задача

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

Решение

Механизм аутентификации построен на основе дополнительных компонент Cocoon, которые предоставляют необходимую функциональность. Так эти компоненты обеспечивают работу с сессиями, позволяют сохранять и вытаскивать данные из пользовательских сессий. Кроме того компонента "action" может использоваться для защиты ресурсов.

Концепция аутентификации на основе обработчиков используется для логической группировки ресурсов. Это означает, что если пользователь прошел процедуру аутентификации в некотором обработчике, то он получает доступ ко всем ресурсам, которые находятся в логической группе этого обработчика. Каждый обработчик можно настроить на проведение процедуры аутентификации через конкретный источник данных. Например, обработчик A может использовать базу данных, а обработчик B может использовать директорию LDAP. На самом деле, процедура аутентификации работает на основе системы компонент Cocoon.

Ниже приводится фрагмент карты сайта Cocoon, где показано, как настроен обработчик.

<map:pipelines>
    <map:component-configurations>
        <authentication-manager>
            <handlers>
                <handler name="portalhandler">
                    <redirect-to uri="cocoon:/sunspotdemoportal"/>
                    <authentication uri="
                        cocoon:raw:/sunrise-authuser"/>
                </handler>
            </handlers>
        </authentication-manager>
    </map:component-configurations>
    ...
</map:pipelines>

Различные обработчики сгруппированы внутри секции authentication-manager. При этом каждый обработчик имеет уникальное имя. Это имя позднее будет использоваться при настройке системы компонент, которую необходимо защитить. При настройке системы компонент с помощью тэга redirect-to можно указать, на какую страницу будет перенаправлен пользователь при попытке получить доступ к защищенной странице, для просмотра которой у него нет прав. Система компонент аутентификации определяется с помощью тэга authentication. Эта система компонент получает данные из формы, например, со страницы входа, а затем удостоверяет их правильность.

При успешной проверке система компонент аутентификации (в данном случае она называется "sunrise-authuser") возвращает XML-данные в специальном формате, который подробно описан в документации к Cocoon. Этот формат является достаточно гибким: дополнительные данные о пользователе можно добавить с помощью описываемой системы компонент и затем использовать в своем приложении.

После определения обработчика и настройки системы компонент аутентификации следует защитить ресурсы. Следующий XML-фрагмент карты сайта иллюстрирует, как можно защитить ресурсы с помощью процедуры аутентификации в связке с уже определенным обработчиком.

<map:match pattern="protected-document">
    <!-- protect this document -->
    <map:act type="auth-protect">
        <map:parameter name="handler" value="portalhandler"/>

        <map:generate src="document.xml"/>
        <map:transform src="to_html.xsl"/>
        <map:serialize/>
    </map:act>
</map:match>

В нашем случае ресурс protected-document "принадлежит" обработчику portalhandler. Если пользователь "вошел" в этот обработчик, то все ресурсы, которые сгруппированы в нем, будут ему доступны. Если же пользователь не вошел в обработчик, то он будет перенаправлен на другую систему компонент, определенную при настройке обработчика. Обычно, в этом случае отображается страница входа, чтобы пользователь мог войти на портал, указав идентификатор и пароль.