Il reindirizzamento JSF2 con includeViewParams consente agli utenti di immettere espressioni EL risolte in campi di testo

Question

Ho una pagina XHTML JSF2 che definisce i parametri di visualizzazione, questo consente di avere URL bookmarkable. La pagina di XHTML comprende i parametri:

<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> 

Nella stessa pagina, ho un campo di testo e un pulsante che permette all'utente di cambiare la searchName:

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

e, infine, la ricerca metodo di azione() nei nbsearchpage fagioli torna alla stessa pagina, ma inclusi i parametri:

?faces-redirect=true&includeViewParams=true 

che fornisce all'utente con un bel URL. Quando l'utente inserisce "IBM" nel campo di ricerca, l'URL viene reindirizzato a

?searchName=IBM 

Funziona perfettamente. Ma ora l'utente può inserire un'espressione EL nel campo di testo SearchName e viene valutata l'espressione EL. Per esempio. quando l'utente immette "# {2 + 2}" nel campo di testo, l'URL viene reindirizzato a

?searchName=4 

e questo è ciò che penso che non dovremmo fare, che permette all'utente di inserire l'espressione EL causa di sicurezza motivi. Sto usando Glassfish 3.1.1.

Qualche idea su come evitare questa risoluzione EL automatica? Penso che ci sia un difetto fondamentale con il concetto di parametro di visualizzazione in JSF2 e con il reindirizzamento? Ho avuto lo stesso problema con l'ambito di visualizzazione che non sopravvive ai reindirizzamenti, e per questo ho dovuto creare un proprio ambito. (Avrei potuto usare l'ambito del flash).

Answer 1

Posso riprodurlo su Mojarra 2.1.4. Questo è sicuramente indesiderabile. L'ho riferito ai ragazzi di Mojarra come issue 2247 (vota se puoi). Tra l'altro MyFaces 2.1.3 espone anche lo stesso problema.

Non viene in mente alcuna soluzione semplice per questo particolare problema, poiché la causa principale si trova in una classe di utilità specifica dell'implementazione JSF. Potresti facilmente avere una copia modificata nel tuo /WEB-INF/classes, ma per essere indipendente dall'implementazione dovresti completamente reimplementare ViewHandlerImpl o forse ExternalContextImpl e fornirlo come uno personalizzato, ma è molto lavoro.

Tuttavia, come si sta già utilizzando <f:viewParam>, si può anche semplicemente usare <form> invece di <h:form> e <input type="submit"> invece di <h:commandButton>:

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

e fare il metodo di azione in fase di pre render vista listener di eventi, invece. Questo è anche un modo più corretto di utilizzare i moduli GET in JSF poiché <h:form> è destinato solo al POST.

---

Estranei al problema concreto:

ho avuto lo stesso problema con il campo di applicazione vista che non sopravvive redirect, e per questo ho dovuto creare un proprio ambito.

redirect Sopravvivere ha mai stato l'intento del campo di applicazione vista. L'ambito di visualizzazione è concepito per vivere finché si interagisce con la stessa vista (in particolare con Ajax e con il re-rendering condizionato del contenuto). Stai fondamentalmente cercando l'ambito della conversazione. Avresti visto CDI @ConversationScoped o MyFaces CODI.

Answer 2

Questo problema è stato risolto in MYFACES-3405 per MyFaces Core versioni 2.0.11, 2.1.5 e in JAVASERVERFACES-2247 per Mojarra versioni 2.0.7, 2.1.5, 2.1.6.

Basta usare una versione aggiornata.