Я использую GlassFish 3.1 и хочу использовать аутентификацию контейнера. Когда я начал писать ограничение безопасности в файле web.xml, у меня было ощущение, что шаблоны URL имеют очень небольшую гибкость. Глава 12.2 в спецификации сервлета 3.0 описывает допустимые шаблоны URL для отображения сервлета:
- Пункт списка
- /что-то/* для сопоставления путей
- *.extension для сопоставления расширений
- точное отображение
- корневые случаи по умолчанию и контекст
12.1 описывает алгоритм сопоставления и в пункте 2 говорится: Контейнер будет рекурсивно пытаться сопоставить самый длинный префикс пути. Это делается путем перехода вниз по дереву путей по каталогу за раз, используя символ «/» в качестве разделителя пути. Самое длинное совпадение определяет выбранный сервлет.
Ограничения безопасности описаны в главе 13, и из 13.8.3 кажется, что шаблоны URL и алгоритм сопоставления такие же, как и для сервлета.
Представьте, что у вас есть унаследованное приложение со страницами JSF, организованными следующим образом: для каждого класса сущностей есть каталог с именем сущности, который содержит 4 файла JSF (список, редактирование, создание, просмотр). Что делать, если вы хотите защитить доступ к редактированию и созданию страниц? Мне кажется, что вы можете использовать только «точное совпадение» в шаблоне URL-адреса, поэтому вам нужно написать ограничение для каждой страницы, которую вы хотите защитить, очень долгое и утомительное действие, подверженное ошибкам. Кроме того, если я защищаю весь каталог правилом сопоставления путей (например, /customers/* ), я не вижу никакого способа снять это ограничение для конкретной страницы внутри этого каталога (например, если требуется чтобы освободить доступ к странице «Список» внутри защищенного каталога).
Во время экспериментов с Glassfish 3.1 я заметил это странное поведение: сопоставления путей работают хорошо, только если они абсолютны из корня контекста, поэтому при использовании конфигурации jsf по умолчанию они должны начинаться с «/faces». Если я напишу /customers/ вместо /faces/customers/, ограничение безопасности не будет оцениваться. По моему мнению, это контрастирует с тем, что указано в 12.1 (сообщено выше).
Может ли кто-нибудь пролить свет на то, как можно эффективно использовать шаблон URL для определения ограничений безопасности? Очевидно, что вы можете поместить все конфиденциальные JSF в каталог '/protected', но это очень инвазивный способ достижения цели с безопасностью, который нарушает любой логический порядок JSF.
Спасибо, Филиппо.
