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

У меня есть страница 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>

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

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

и, наконец, метод поиска действий() в nbsearchpage bean возвращается на ту же страницу, но включает в себя параметры:

?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 и с перенаправлением? У меня была та же проблема с областью представления, которая не переносит перенаправления, и для этого мне пришлось создать собственную область. (Я мог бы использовать флэш-область).

Ответы

Ответ 1

Я могу воспроизвести это на Mojarra 2.1.4. Это определенно нежелательно. Я сообщил об этом ребятам Mojarra в качестве issue 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 или MyDaces CODI.

Ответ 2

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

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