2011-11-17 19 views
11

Tôi có trang XHTML JSF2 xác định tham số xem, điều này cho phép người dùng có các URL có thể đánh dấu trang. Các trang XHTML bao gồm các thông số:Chuyển hướng JSF2 với includeViewParams cho phép người dùng nhập biểu thức EL được giải quyết vào trường văn bản

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

Trên cùng một trang, tôi có một trường văn bản và một nút cho phép người dùng thay đổi searchName:

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

và cuối cùng, việc tìm kiếm phương pháp hành động() trong bean nbsearchpage trở về cùng một trang, nhưng bao gồm các tham số:

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

cung cấp cho người dùng một URL đẹp. Khi người dùng nhập "IBM" vào trường tìm kiếm, URL được chuyển hướng đến

?searchName=IBM 

Nó hoạt động hoàn toàn tốt. Nhưng bây giờ người dùng có thể nhập một biểu thức EL trong trường văn bản searchName và biểu thức EL được đánh giá. Ví dụ. khi người dùng nhập "# {2 + 2}" trong textfield, URL được chuyển hướng đến

?searchName=4 

và đây là những gì tôi nghĩ chúng ta không nên làm, cho phép người dùng nhập vào biểu EL do an ninh lý do. Tôi đang sử dụng Glassfish 3.1.1.

Bất kỳ ý tưởng nào về cách ngăn EL tự động này giải quyết? Tôi nghĩ rằng có một lỗ hổng cơ bản với khái niệm tham số khung nhìn trong JSF2 và với chuyển hướng? Tôi đã có cùng một vấn đề với phạm vi xem không tồn tại chuyển hướng, và cho điều này tôi đã phải tạo ra một phạm vi riêng. (Tôi có thể đã sử dụng phạm vi flash).

+1

Tôi có thể tạo lại điều này với Mojarra 2.1.2, đây là một lỗ hổng bảo mật nghiêm trọng vì nó cũng cho phép truy cập vào các thuộc tính phiên và gọi các phương thức tùy ý. –

Trả lời

5

Tôi có thể tái tạo điều này trên Mojarra 2.1.4. Điều này chắc chắn không thể hiểu được. Tôi đã báo cáo cho những người Mojarra là issue 2247 (bỏ phiếu cho nó nếu bạn có thể). MyFaces 2.1.3 bằng cách này cũng cho thấy cùng một vấn đề.

Không có cách giải quyết đơn giản nào cho vấn đề cụ thể này đến với đầu óc cho đến nay vì nguyên nhân gốc là trong lớp tiện ích cụ thể triển khai JSF. Bạn có thể dễ dàng có một bản sao sửa đổi trong /WEB-INF/classes của mình, nhưng để được triển khai độc lập, bạn phải hoàn toàn thực hiện lại ViewHandlerImpl hoặc có thể ExternalContextImpl và cung cấp nó như một tùy chỉnh, nhưng đó là rất nhiều công việc.

Tuy nhiên, như bạn đã sử dụng <f:viewParam>, bạn cũng có thể chỉ cần sử dụng <form> thay vì <h:form><input type="submit"> thay vì <h:commandButton>:

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

và làm phương pháp hành động trong pre render xem sự kiện người nghe để thay thế. Đó cũng là cách thích hợp hơn khi sử dụng biểu mẫu GET trong JSF vì <h:form> chỉ dành cho POST.


Không liên quan cho vấn đề cụ thể:

tôi đã cùng một vấn đề với phạm vi quan điểm cho rằng không tồn tại chuyển hướng, và cho điều này tôi đã phải tạo ra một phạm vi riêng.

đổi hướng Sống sót có bao giờ được mục đích của phạm vi xem. Phạm vi khung nhìn được định hướng để sống miễn là bạn đang tương tác với cùng một chế độ xem (đặc biệt là bằng Ajax và hiển thị lại nội dung có điều kiện). Về cơ bản, bạn đang tìm kiếm phạm vi hội thoại. Bạn đã xem xét số @ConversationScoped hoặc MyFaces CODI của CDI.

1

Sự cố này đã được giải quyết trong MYFACES-3405 cho MyFaces Core phiên bản 2.0.11, 2.1.5 và trong JAVASERVERFACES-2247 cho các phiên bản Mojarra 2.0.7, 2.1.5, 2.1.6.

Chỉ cần sử dụng phiên bản cập nhật.

Các vấn đề liên quan