Новости
- Серія контенту:
- Цей контент є частиною серії: Забезпечення безпеки Java-додатків за допомогою Acegi
- Посилення безпеки без створення Java коду
- Розвіюємо помилки
- Розгортання Acegi для захисту JSF-додатки
- Лістинг 1. Файл web.xml file для установки Acegi і JSF в сервлет-контейнер
- Передача параметрів контексту в Acegi і JSF
- Конфігурація оброблювачів для Acegi і JSF
- Конфігурація і прив'язка до URL-шаблонами фільтрів сервлетів
- Конфігурація JSF-сервлета
- Запуск JSF-Acegi додатки
- Малюнок 1. Послідовність подій при запуску JSF-Acegi додатки
- Обробка запиту до JSF-сторінці, захищеної Acegi
- Малюнок 2. Спільна робота JSF і Acegi для видачі JSF-сторінки клієнту
- Приклад JSF-Acegi додатки
- Висновок
- Ресурси для скачування
Забезпечення безпеки Java-додатків за допомогою Acegi
Настроюється система безпеки для JavaServer Faces-додатків
Серія контенту:
Цей контент є частиною # з серії # статей: Забезпечення безпеки Java-додатків за допомогою Acegi
https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Обеспечение+безопасности+java-приложений+с+помощью+acegi
Слідкуйте за виходом нових статей цієї серії.
Цей контент є частиною серії: Забезпечення безпеки Java-додатків за допомогою Acegi
Слідкуйте за виходом нових статей цієї серії.
Перші три частини цієї серії статей знайомлять з використанням інфраструктури безпеки Acegi (Acegi Security System) для захисту корпоративних Java-додатків:
- Перша частина показує, як використовувати вбудовані фільтри Acegi для реалізації простої системи безпеки, заснованої на URL.
- Друга частина показує, як написати політику контролю доступу, зберегти її в сервері каталогів LDAP і налаштувати Acegi для взаємодії з LDAP-сервером для реалізації цієї політики.
- Третя частина показує, як використовувати Acegi для захисту доступу до екземплярів Java-класів в корпоративних додатках.
У цій четвертій статті розповідається, як використовувати Acegi для захисту JavaServer Faces (JSF)-додатків, що працюють в сервлет-контейнері. Спочатку пояснюється, які можливості надає Acegi для цього завдання, і розвіюються деякі загальні помилки про використання Acegi і JSF. Потім в статті представлений простий файл web.xml, який можна використовувати для розгортання Acegi для захисту JSF-додатки. Далі стаття переходить до внутрішньої структурі Acegi і JSF-компонентів для розуміння послідовності подій, які відбуваються при установці файлу web.xml і при зверненні користувача до JSF-додатком. Стаття завершується прикладом JSF-додатки, захищеного Acegi.
Посилення безпеки без створення Java коду
Повернемося до першого в цій серії наприклад Acegi-додатки (див. Розділ "Просте додаток Acegi" в першій частині ). Ця програма використовує Acegi для реалізації наступних функцій безпеки:
- Видача сторінки для входу в систему, коли нерозпізнаних користувачів намагається звернутися до захищеного ресурсу.
- Перенаправлення авторизованого користувача безпосередньо до зажадати захищеному ресурсу.
- Видача сторінки "відмовлено в доступі" якщо користувач не авторизований для доступу до захищеного ресурсу.
Важливо пам'ятати, що не потрібно писати ніякого Java-коду для отримання цих можливостей. Необхідно тільки налаштувати Acegi. Також можливо отримати ці можливості від Acegi в JSF-додатку без написання будь-якого Java-коду.
Розвіюємо помилки
Деякі автори, мабуть, вважають, що інтеграція Acegi з JSF вимагає, щоб JSF-додаток надавало сторінку для входу в систему (див. Розділ ресурси ). Це не правда. Це обов'язок Acegi - видавати сторінку для входу в систему, коли вона буде потрібна. Також Acegi гарантує, що сторінка для входу в систему буде видана тільки один раз протягом захищеного сеансу. Аутентифіковані й авторизовані користувачі можуть запросити захищений ресурс без повторного виконання процедури входу в систему.
Якщо використовувати JSF для видачі сторінки входу в систему, то виникають дві основні проблеми:
- Не використовуються можливості Acegi для обслуговування сторінки для входу в систему, коли вона потрібна. Необхідно написати Java-код для реалізації всієї логіки, яка обслуговує сторінку для входу в систему.
- Необхідно написати кілька Java-коду для передачі параметрів, що ідентифікують користувача, наприклад, ім'я користувача та пароль зі сторінки для входу в систему JSF в Acegi.
Acegi задумана як альтернатива написання коду, що забезпечує безпеку в Java. Використання JSF для обслуговування сторінки для входу в систему суперечить цієї мети і призводить до виникнення безлічі проблем з інтеграцією JSF і Acegi, більшість з яких пов'язані з фактом, що Acegi призначена для реалізації настроюється безпеки. Якщо використовувати JSF для виконання роботи Acegi, можуть виникнути проблеми.
Частина, що залишилася цієї статті пояснює і демонструє, як можна розробляти JSF-додатки незалежно від Acegi і надалі конфігурувати Acegi для захисту JSF-додатків без необхідності написання будь-якого Java-коду. Почнемо з вивчення файлу web.xml, який можна розгорнути для захисту JSF-додатки.
Розгортання Acegi для захисту JSF-додатки
В лістингу 1 показаний файл web.xml (часто званий дескриптором розгортання - deployment descriptor), який можна використовувати для розгортання Acegi з метою захисту JSF-додатків, які працюють всередині сервлет-контейнера (такого як Apache Tomcat):
Лістинг 1. Файл web.xml file для установки Acegi і JSF в сервлет-контейнер
<? Xml version = "1.0"?> <! DOCTYPE web-app PUBLIC "- // Sun Microsystems, Inc.//DTD Web Application 2.3 // EN" "http://java.sun.com/dtd/web -app_2_3.dtd "> <web-app> <context-param> <param-name> contextConfigLocation </ param-name> <param-value> /WEB-INF/acegi-config.xml </ param-value> < / context-param> <context-param> <param-name> javax.faces.STATE_SAVING_METHOD </ param-name> <param-value> server </ param-value> </ context-param> <context-param> < param-name> javax.faces.CONFIG_FILES </ param-name> <param-value> /WEB-INF/faces-config.xml </ param-value> </ context-param> <listener> <listener-class> org.springframework.web.context.ContextLoaderListener </ listener-class> </ listener> <listener> <listener-class> com.sun.faces.config.ConfigureListener </ listener-class> </ listener> <! - сервлет Faces (основний компонент JSF-додатки) -> <servlet> <servlet-name> Faces Servlet </ servlet-name> <servlet-class> javax.faces.webapp.FacesServlet </ servlet-class> <load-on -startup> 1 </ load-on-st artup> </ servlet> <! - URL-шаблон, відповідний Faces сервлету -> <servlet-mapping> <servlet-name> Faces Servlet </ servlet-name> <url-pattern> *. faces </ url- pattern> </ servlet-mapping> <! - конфігурація фільтра Acegi -> <filter> <filter-name> Acegi Filter Chain Proxy </ filter-name> <filter-class> org.acegisecurity.util.FilterToBeanProxy </ filter-class> <init-param> <param-name> targetClass </ param-name> <param-value> org.acegisecurity.util.FilterChainProxy </ param-value> </ init-param> </ filter> < ! - URL-шаблон, відповідний фільтру Acegi -> <filter-mapping> <filter-name> Acegi Filter Chain Proxy </ filter-name> <url-pattern> / * </ url-pattern> </ filter- mapping> </ web-app>
Важливо відзначити, що лістинг 1 містить такі ключові слова:
- Три тега <context-param> (параметр контексту)
- Два тега <listener> (обробник подій)
- Один тег <filter> (фільтр)
- Один тег <servlet> (сервлет)
- Один тег <servlet-mapping> (URL-шаблон для сервлета)
- Один тег <filter-mapping> (URL-шаблон для фільтра)
Далі розглядається призначення кожного з цих тегів в додатку JSF-Acegi.
Передача параметрів контексту в Acegi і JSF
Кожен тег <context-param> в лістингу 1 визначає параметр, який потрібно Acegi або JSF під час запуску або роботи. Перший параметр contextConfigLocation визначає місце розташування конфігураційного XML файлу Acegi.
Параметри javax.faces.STATE_SAVING_METHOD і javax.faces.CONFIG_FILES потрібні для JSF. Параметр javax.faces.STATE_SAVING_METHOD визначає, як передбачається зберігати стан уявлення JSF-сторінки: на клієнті або на сервері. За замовчуванням еталонна реалізація JSF від Sun зберігає уявлення JSF на сервері.
Параметр javax.faces.CONFIG_FILES визначає місце розташування конфігураційних файлів, потрібних для JSF. Детальна інформація про конфігураційних файлах виходить за рамки цієї статті. (В розділі ресурси представлені посилання на матеріали по цій темі.)
Конфігурація оброблювачів для Acegi і JSF
Тепер розглянемо два тега <listener> в лістингу 1 . Теги <listener> визначають класи оброблювачів, які прослуховують і обробляють певні події, що виникають під час запуску або виконання JSP або сервлет-додатки. Параметри тега можуть включати обробники наступних подій:
- Сервлет-контейнер створює новий контекст сервлету (servlet context) при запуску JSP або сервлет-додатки. Ця подія виникає кожен раз, коли запускається JSP або сервлет-додаток.
- Сервлет-контейнер створює новий об'єкт запиту для сервлета (servlet request). Ця подія трапляється щораз, коли контейнер отримує HTTP-запит від клієнта.
- Встановлюється новий HTTP-сеанс з користувачем. Ця подія відбувається, коли запитувач клієнт встановлює HTTP-сеанс з сервлет-контейнером.
- Доповнити новим атрибут в об'єкти контексту сервлета, запиту сервлету або HTTP-сеансу.
- Змінюється або віддаляється існуючий атрибут з об'єктів контексту сервлета, запиту сервлету або HTTP-сеансу.
Тег <listener> - це механізм розширення, що дозволяє з додатком, що працює всередині сервлет-контейнера виконувати обробку в зв'язку з певними подіями. У специфікації сервлетів визначені кілька інтерфейсів, які повинні реалізовувати класи-обробники для обробки подій.
Наприклад, в інфраструктурі Spring Framework реалізується інтерфейс обробки подій для контексту сервлета - javax.servlet.ServletContextListener. В інфраструктурі Spring, клас, який реалізує цей інтерфейс, називається org.springframework.web.context.ContextLoaderListener. Можна побачити цей клас-обробник в першому тезі <listener> в лістингу 1 .
Точно так же JSF надає клас com.sun.faces.config.ConfigureListener, який реалізує кілька інтерфейсів для обробки подій. Клас ConfigureListener можна знайти в другому тезі <listener> в лістингу 1 .
Далі в статті розглядаються різні інтерфейси для обробки подій і обробку даних, виконувати всередині класів обробників подій Acegi і JSF (див. Розділи " Запуск JSF-Acegi додатки "І" Обробка запиту до JSF-сторінці, захищеної Acegi ").
Конфігурація і прив'язка до URL-шаблонами фільтрів сервлетів
Тепер зверніть увагу на тег <filter> в лістингу 1 . Сервлет-програм така сама фільтри для попередньої обробки вхідних запитів, перш ніж запитуваний сервлет зможе обробити їх. Acegi використовує фільтри сервлетів для аутентифікації користувачів перед обробкою запиту.
У тезі <filter> в лістингу 1 є дочірній елемент <filter-class>, що визначає клас org.acegisecurity.util.FilterToBeanProxy. Клас FilterToBeanProxy - це один з компонентів Acegi. Цей клас реалізує інтерфейс, javax.servlet.Filter, який входить в специфікацію сервлетів. В інтерфейсі javax.servlet.Filter є метод doFilter (), який викликається сервлет-контейнером при отриманні запиту.
також в лістингу 1 у тега <filter> є інший дочірній елемент <init-param>. Тег <init-param> визначає параметри, необхідні для створення екземпляра класу FilterToBeanProxy. Як видно з лістингу 1 , Класу FilterToBeanProxy необхідний тільки один параметр - об'єкт класу FilterChainProxy. Клас FilterChainProxy представляє повний ланцюжок фільтрів Acegi, що обговорювалися в першій частині (Див. Розділ "Security Filters"). Метод doFilter () класу FilterToBeanProxy використовує клас FilterChainProxy для запуску ланцюжка фільтрів безпеки Acegi.
Тег <filter-mapping> в лістингу 1 визначає ULR запиту, при якому викликається FilterToBeanProxy. В даному прикладі всі JSF-сторінки просто прив'язані до класу Acegi FilterToBeanProxy. Це означає, що управління автоматично переходить в метод FilterChainProxydoFilter (), коли користувач намагається отримати доступ до JSF-сторінці.
Конфігурація JSF-сервлета
Тег <servlet> в файлі web.xml визначає сервлет (в даному випадку - JSF-сервлет), який можна викликати за певним URL. Тег <servlet-mapping> визначає цей URL. Практично всі JSP- або сервлет-додатки містять ці два тега, так що немає необхідності їх докладного обговорення. (В розділі ресурси наведені посилання на матеріали, в яких розглядаються основи програмування Java-сервлетов.)
До цього моменту були розглянуті всі теги в файлі web.xml, необхідні для розгортання Acegi для захисту JSF-додатки. Також було показано, як обробники подій, сервлети і фільтри взаємодіють один з одним. Як можна припустити, якщо встановити файл web.xml з лістингу 1 в сервлет-контейнер, Acegi і JSF спробують виконати певні дії в наступних двох випадках:
- Під час запуску програми;
- коли додаток отримує запит до JSF-сторінці.
У наступних двох розділах розбираються послідовності подій, що відбуваються в цих двох випадках.
Запуск JSF-Acegi додатки
на малюнку 1 показана послідовність подій, які відбуваються під час запуску JSF-Acegi програми:
Малюнок 1. Послідовність подій при запуску JSF-Acegi додатки
Більш докладно послідовність подій, зображена на малюнку 1 , Описана нижче:
- Сервлет-контейнер створює екземпляри всіх обробників, сконфигурированних в файлі web.xml.
- Сервлет-контейнер реєструє клас Acegi ContextLoaderListener як класу-обробника, який реалізує інтерфейс javax.servlet.ServletContextListener. Цей інтерфейс ServletContextListener містить два важливих методу: contextInitialized () і contextDestroyed ():
- Метод contextInitialized () отримує управління, коли инициализируется контекст сервлету.
- Подібним чином метод contextDestroyed () викликається при видаленні контексту сервлета під час завершення роботи програми.
- Сервлет контейнер реєструє клас JSF ConfigureListener в якості іншого обробника подій. Клас JSF ConfigureListener реалізує відразу кілька інтерфейсів для обробки подій, таких як ServletContextListener, ServletContextAttributeListener, ServletRequestListener і ServletRequestAttributeListener. Методи інтерфейсу ServletContextListener вже розглядалися. Решта інтерфейси - це:
- ServletContextAttributeListener, що містить три методи: attributeAdded (), attributeRemoved () і attributeReplaced (). Відповідно ці методи отримують управління, коли атрибут додається в контекст сервлету, видаляється з контексту сервлета або замінюється новим атрибутом. Метод attributeReplaced () отримує управління на кроці 8 в послідовності дій при обробці запиту до JSF-сторінці, захищеної Acegi .
- ServletRequestListener, який містить методи, які отримують управління коли новий об'єкт запиту сервлету створюється або видаляється. Цей об'єкт запиту для сервлета служить оболонкою для запиту від користувача.
- ServletRequestAttributeListener, що містить методи, які отримують управління, коли атрибут додається, видаляється або замінюється в запиті сервлету. Далі в статті обговорюється обробка, яку виконує клас JSF ConfigureListener, коли новий об'єкт запиту сервлету створюється на кроці 3 послідовності дій при обробці запиту до JSF-сторінці, захищеної Acegi .
- Сервлет-контейнер створює об'єкт контексту сервлета, який служить оболонкою для ресурсів програми (таких як JSP-сторінки, Java-класи та параметри ініціалізації програми) і дозволяє всьому додатком отримувати доступ до ресурсів. Всі інші компоненти JSF-Acegi додатки (обробники, фільтри і сервлети) зберігають інформацію про ресурсах додатка в формі атрибутів в об'єкті контексту сервлета.
- Сервлет-контейнер сповіщає компонент Acegi ContextLoaderListener про ініціалізації контексту сервлета викликом методу contextInitializated () інтерфейсу ContextLoaderListener.
- Метод contextInitialized () аналізує конфігураційний файл Acegi, створює контекст Web-додатки для JSF-Acegi додатки і створює екземпляри всіх фільтрів безпеки і Java beans-компонентів, налаштованих в файлі конфігурації Acegi. Ці екземпляри фільтрів потім використовуються при аутентифікації і авторизації, коли JSF-додаток отримує запит від клієнта (див. Опис створення контексту Web-додатки, що відноситься до малюнка 1 в третій частині серії).
- Сервлет-контейнер оповіщає компонент JSF ConfigureListener про ініціалізації контексту сервлета викликом методу contextInitialized ().
- Метод contextInitialized () перевіряє всі Java beans-компоненти, керовані JSF і певні в конфігураційних файлах JSF, щоб переконатися, що для кожного bean-компонента існують Java-класи.
- Сервлет-контейнер перевіряє файл web.xml на предмет наявності будь-яких сконфигурированних фільтрів. Наприклад, у файлі web.xml в лістингу 1 міститься фільтр Acegi з назвою FilterToBeanProxy, екземпляр якого сервлет-контейнер створює, инициализирует і реєструє в якості фільтра. Тепер Acegi готова для обробки вхідних запитів на предмет аутентифікації і авторизації.
- Сервлет-контейнер створює екземпляр Faces сервлету, який починає очікувати вхідних запитів від користувачів.
У наступному розділі розглядається послідовність подій, що виникають, коли JSF-Acegi додаток отримує запит від користувача.
Обробка запиту до JSF-сторінці, захищеної Acegi
Раніше було розказано, як налаштувати Acegi для захисту JSF-додатки. Також була розглянута послідовність подій, що відбуваються при запуску JSF-Acegi додатки. У цьому розділі описується, як компоненти JSF і Acegi працюють разом всередині інфраструктури сервлет-контейнера, коли користувач відправляє запит до JSF-сторінці, захищеної Acegi.
на малюнку 2 представлена послідовність подій, що відбуваються, коли користувач відправляє запит до JSF-сторінці, захищеної Acegi:
Малюнок 2. Спільна робота JSF і Acegi для видачі JSF-сторінки клієнту
Детально послідовність подій, зображених на малюнку 2 , Описана нижче:
- Сервлет-контейнер створює об'єкт запиту сервлету, что представляет запит від користувача.
- Если вернуться до Кроку 3 в послідовності Дій при запуску JSF-Acegi Додатки , То там йдет про ті, что клас JSF ConfigureListener реалізує інтерфейс ServletRequestListener. Це означає, что ConfigureListener обробляє події, пов'язані зі Створення і відалення об'єктів запиту сервлету. Тому сервлет-контейнер віклікає метод requestInitialized () класу ConfigureListener.
- Метод requestInitialized () готовится к Виконання життєвого циклу запиту, як це описано в Специфікації JSF. Підготовка Включає в себе перевірку того, что для запиту існує Faces-контекст (Faces context - контекст JSF-компонентів). Faces-контекст служити оболонка для ресурсов програми, Які пізніше будут потрібні Faces-сервлету для Виконання життєвого циклу JSF. Faces-контекст відсутній, если цею запит є дерло в новому сеансі роботи з комерційними користувачем. У цьом випадка метод requestInitialized () створює новий Faces-контекст.
- Сервлет-контейнер перевіряє, чи є в запіті користувача будь-яка інформація про стан. Якщо сервлет-контейнер не знаходить інформації про стан, він передбачає, що цей запит є першим в новому сеансі взаємодії з користувачем, і створює для користувача об'єкт HTTP-сеансу. Якщо сервлет-контейнер виявляє, що запит містить інформацію про стан (наприклад, cookie або інформацію про стан в рядку URL), він відновлює попередній сеанс взаємодії з користувачем, грунтуючись на отриманої інформації про сеанс.
- Сервлет-контейнер зіставляє URL запиту з URL-шаблоном, певним всередині дочірнього елемента <url-pattern> тега <filter-mapping> в дескрипторі розгортання. Якщо URL-запиту відповідає URL-шаблоном, то сервлет-контейнер викликає компонент Acegi FilterToBeanProxy, зареєстрований як фільтр сервлету на кроці 9 малюнка 1 .
- FilterToBeanProxy використовує клас FilterChainProxy для проходження по всьому ланцюжку фільтрів безпеки Acegi. Фільтри Acegi автоматично перевіряють об'єкт HTTP-сеансу, створений на кроці 4, для перевірки того, що запитувач клієнт вже аутентифікований. Якщо Acegi виявляє, що користувач не аутентифікований, вона видає сторінку для входу в систему. В іншому випадку вона безпосередньо звертається до процесу авторизації, описаного в розділі "Configuring the interceptor" во второй части .
- Acegi оновлює контекст сервлету, додаючи інформацію про аутентифицироваться сеансі взаємодії з користувачем.
- Сервлет-контейнер сповіщає метод attributeReplaced () класу JSF ConfigureListener, що контекст сервлету був оновлений. Компонент ConfigureListener перевіряє, чи були змінені будь-які з JSF Java Beans-компонентів. Якщо виявляються які-небудь зміни, то Faces-контекст оновлюється відповідним чином. Однак в цьому випадку під час аутентифікації Acegi не змінює Java beans-компоненти, керовані JSF, так що ConfigureListener не виконує ніякої роботи під час виклику цього методу.
- Якщо процес авторизації проходить успішно, то управління передається в Faces-сервлет, який виконує життєвий цикл JSF і готує відповідь для відправки назад клієнту.
Тепер, коли було розглянуто, як JSF і Acegi працюю разом для обробки JSF-запиту, прийшов час на практиці вивчити спільну роботу JSF і Acegi.
Приклад JSF-Acegi додатки
Матеріали для скачування, представлені в цій статті (див. Розділ завантаження ), Містять приклад JSF-Acegi додатки - JSFAcegiSample, в якому демонструється проста інтеграція Acegi і JSF. У прикладі використовується файл web.xml, наведений в лістингу 1 .
Для установки прикладу програми необхідно виконати дві дії з розділу "Розгортання і запуск програми" в першій части . Також буде потрібно завантажити і розпакувати файл jsf-1_1_01.zip з сайту Sun JSF (див. Розділ ресурси ), А потім скопіювати файли з архіву jsf-1.1.X.zip в папку WEB-INF / lib в каталозі JSFAcegiSample.
Приклад програми можна викликати, ввівши в Web-браузері наступну URL: http: // localhost: 8080 / JSFAcegiSample. Приклад JSFAcegiSample відображає стартову сторінку, яка містить посилання на захищені ресурси і сторінку для входу в систему. Всі захищені компоненти розроблені з використанням JSF-компонентів, тоді як Acegi надає сторінку для входу в систему і виконує аутентифікацію та авторизацію.
Висновок
У цій статті розповідається, як налаштувати Acegi для захисту JSF-додатків. Також детально розібрано, як JSF і Acegi компоненти працюють разом всередині інфраструктури сервлет-контейнера. В кінці наведено приклад запуску JSF-Acegi додатки.
Є ще кілька аспектів, що стосуються реалізації безпеки JSF-додатків за допомогою Acegi, які варто розглянути. У наступній статті цієї серії розглядається, як використовувати Acegi для організації захисту доступу до Java Beans-компонентів, керованим JSF.
Ресурси для скачування
Схожі тими
- Securing Java applications with Acegi, Part 4: Protecting JSF applications1 : (EN) оригінал статті.
- Securing Java applications with Acegi : Ця серія статей знайомить з використанням системи безпеки Acegi для захисту корпоративних Java-додатків.
- Securing Java applications with Acegi, Part 1: Architectural overview and security filters (Bilal Siddiqui, developerWorks, березень 2007 р): ця стаття знайомить з архітектурою і компонентами системи безпеки Acegi.
- Securing Java applications with Acegi, Part 2: Working with an LDAP directory server (Bilal Siddiqui, developerWorks, травень 2007 року): в цій статті демонструється Acegi з серверами каталогів.
- Securing Java applications with Acegi, Part 3: Access control for Java objects (Bilal Siddiqui, developerWorks, вересень 2007 р): в цій статті показується, як організувати контроль за доступом до Java об'єктів.
- Acegi Security System : Web-сайт Acegi - перше місце, куди варто звернутися за інформацією.
- JSF and Acegi (EN): в цьому записі на MyFaces WIKI, присвяченій інтеграції JSF і Acegi, розглядається використання bean-компонентів JSF для захисту JSF-додатків.
- Another Faces in your Face: Acegi / JSF solution addendum (Tony L. Kerz, Fair Trade Java Stack Blog, лютий 2006 року) і Integrating Acegi with JSF (Victor Tatai, sometimes i feel like screaming ..., жовтень 2005 року): в цьому блозі обговорюється стратегія інтеграції Acegi і JSF.
- ACEGI JSF Components hit the stores (Блог Cagatay Civici, січень 2006 р) (EN): записи в цьому блозі присвячені розробці JSF-компонентів для аутентифікації і авторизації за допомогою Acegi.
- Apache MyFaces forum (EN): на цьому форумі обговорюється використання спеціальних тегів JSF для інтеграції JSF і Acegi.
- Story of a Servlet: An Instant Tutorial (Mark Andrews, java.sun.com) (EN): стаття про основи програмування Java сервлетів.
- Getting started with JavaServer Faces 1.2 (Richard Hightower, developerWorks, грудень 2007 року і січень 2008 року) (EN): короткий курс з двох частин, що знайомить з останньою версією JSF.
- JavaServer Faces Technology : Завантажити реалізацію JSF з Web-сайту компанії Sun. (EN)
- Acegi Security System : Завантажити систему безпеки Acegi. (EN)
- розділ технологія Java : Сайту developerWorks: сотні статей про всі аспекти Java-програмування.
Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів
Jsp?