Web.xml: почему такая низкая гибкость для шаблонов URL в ограничениях безопасности? - PullRequest
0 голосов
/ 22 августа 2011

Я использую GlassFish 3.1 и хотел использовать аутентификацию контейнера. Когда я начал писать ограничения безопасности в web.xml, у меня было ощущение, что шаблоны URL имеют очень небольшую гибкость. Глава 12.2 в спецификации 3.0 сервлета описывает допустимые шаблоны URL для отображения сервлета:

  1. Элемент списка
  2. / что-то / * для отображения пути
  3. *. Расширение для сопоставления расширений
  4. точное отображение
  5. стандартные и контекстные корневые регистры

12.1 описывает алгоритм сопоставления и в точке 2 говорится: Контейнер будет рекурсивно пытаться найти самый длинный префикс пути. Готово переходя вниз по дереву пути к каталогу за раз, используя символ «/» в качестве разделитель пути. Самое длинное совпадение определяет выбранный сервлет.

Ограничения безопасности описаны в главе 13, и из 13.8.3 кажется, что шаблоны URL и алгоритм сопоставления те же, что и для сервлета.

Представьте, что у вас есть устаревшее приложение со страницами JSF, организованное следующим образом: для каждого класса сущности есть каталог с именем сущности, который содержит 4 файла JSF (список, редактирование, создание, просмотр). Что если вы хотите защитить доступ к редактированию и созданию страниц? Мне кажется, что вы можете использовать только «точное соответствие» в шаблоне url, поэтому вам нужно написать ограничение для каждой страницы, которую вы хотите защитить, очень долгое и утомительное, подверженное ошибкам действие. Кроме того, если я защищаю весь каталог с помощью правила сопоставления путей (например, / Customers / *), я не вижу способа снять это ограничение для конкретной страницы в этом каталоге (например, если требуется освободить доступ к странице «Список» внутри защищенного каталога).

Во время экспериментов со Glassfish 3.1 я замечаю это странное поведение: сопоставления путей работают хорошо, только если они являются абсолютными от корневого контекста, поэтому при использовании конфигурации по умолчанию jsf они должны начинаться с ' /face '. Если я пишу / Customers / вместо / Faces / Customers / , ограничение безопасности не оценивается. По моему мнению, это противоречит тому, что указано в 12.1 (сообщалось выше).

Может ли кто-нибудь пролить свет на то, как можно эффективно использовать шаблон url для определения ограничений безопасности? Очевидно, что вы можете поместить всю чувствительную JSF в каталог ' / protected ', но это очень агрессивный способ достижения цели с безопасностью, нарушающей любой логический порядок JSF.

Спасибо Filippo

1 Ответ

1 голос
/ 22 августа 2011

Может кто-нибудь пролить свет на то, как можно эффективно использовать шаблон url для определения ограничений безопасности?

Не могу, после нескольких лет Java EE я чувствую, что Java EEограничения безопасности полезны только для аутентификации.Если речь идет об авторизации (это известная организация, уполномоченная выполнять определенное действие), эта модель безопасности не работает, поскольку она слишком общая (зависит от URL).Вы могли бы взглянуть, например, на Spring Security.В зависимости от сложности варианта использования вы можете рассмотреть возможность самостоятельной сборки - особенно когда речь идет о защите данных (например, только пользователи в организации A могут изменять данные, предоставленные организацией B).

Недействительно ответ, но мое мнение ...

...