Редирект JSF2 с includeViewParams позволяет пользователям вводить EL выражение, которое разрешается в текстовые поля - PullRequest
Новая
       43

Редирект JSF2 с includeViewParams позволяет пользователям вводить EL выражение, которое разрешается в текстовые поля

13 голосов
/ 17 ноября 2011

У меня есть страница JSF2 XHTML, которая определяет параметры просмотра, это позволяет иметь закладки URL.Страница XHTML содержит параметры: 

<f:metadata>
  <f:viewParam name="searchName" value="#{nbsearchpage.searchName}" />
  <!-- More view parameters omitted here for brevity -->
  <f:event listener="#{nbsearchpage.searchPreRender}" type="javax.faces.event.PreRenderViewEvent" />
</f:metadata>

На той же странице у меня есть текстовое поле и кнопка, которая позволяет пользователю изменять searchName: 

<h:form id="some-id">
  <h:inputText value="#{nbsearchpage.searchName}" />
  <h:commandButton value="search" action="#{nbsearchpage.search}" />
</h:form>

и, наконец,метод действия search () в bean-компоненте nbsearchpage возвращает на ту же страницу, но с параметрами: 

?faces-redirect=true&amp;includeViewParams=true

, которые предоставляют пользователю приятный URL.Когда пользователь вводит «IBM» в поле поиска, URL-адрес перенаправляется на 

?searchName=IBM

. Он отлично работает.Но теперь пользователь может ввести выражение EL в текстовое поле searchName, и выражение EL будет оценено.Например, когда пользователь вводит «# {2 + 2}» в текстовое поле, URL-адрес перенаправляется на 

?searchName=4

, и я думаю, что этого делать не следует, что позволяет пользователю вводить выражение ELпо соображениям безопасности.Я использую Glassfish 3.1.1.

Есть идеи, как предотвратить автоматическое разрешение EL?Я думаю, что есть принципиальный недостаток с концепцией параметров представления в JSF2 и с перенаправлением?У меня была такая же проблема с областью представления, которая не сохраняется перенаправлениями, и для этого мне пришлось создать собственную область.(Я мог бы использовать флеш прицел).

Ответы [ 2 ]

5 голосов
/ 17 ноября 2011

Я могу воспроизвести это на Мохарре 2.1.4. Это определенно нежелательно. Я сообщил об этом ребятам из Мохарры как выпуск 2247 (проголосуйте за него, если сможете). MyFaces 2.1.3, кстати, также выявляет ту же проблему.

Никакого простого обходного пути для этой конкретной проблемы не приходит на ум, поскольку основная причина заключается в классе утилит, специфичных для реализации JSF. Вы можете легко иметь измененную копию в /WEB-INF/classes, но чтобы быть независимой от реализации, вам придется полностью переопределить ViewHandlerImpl или, может быть, ExternalContextImpl и предоставить ее как собственную, но это большая работа.

Однако, поскольку вы уже используете <f:viewParam>, вы также можете просто использовать <form> вместо <h:form> и <input type="submit"> вместо <h:commandButton>: 

<form>
  <h:inputText id="searchName" value="#{nbsearchpage.searchName}" />
  <input type="submit" value="search" />
</form>

и вместо этого сделайте метод действия в прослушивателе событий представления предварительного рендеринга. Это также более правильный способ использования форм GET в JSF, поскольку <h:form> предназначен только для POST.

Не связано с конкретной проблемой:

У меня была такая же проблема с областью просмотра, которая не сохраняется перенаправлениями, и для этого мне пришлось создать собственную область.

Выжившие перенаправления никогда не были целью области просмотра. Предполагается, что область действия представления будет жить до тех пор, пока вы взаимодействуете с одним и тем же представлением (особенно с помощью Ajax и условного повторного рендеринга содержимого). Вы в основном ищете область разговора вместо этого. Вы бы посмотрели на CDI @ConversationScoped или MyFaces CODI .

1 голос
/ 17 апреля 2013

Эта проблема была решена в MYFACES-3405 для MyFaces Core версий 2.0.11, 2.1.5 и в JAVASERVERFACES-2247 для Mojarra версий 2.0.7, 2.1.5 2.1.6.

Просто используйте обновленную версию.

...