I am running an jsf2.2 application and using Primefaces with JAVA 1.6, i am trying to disable the client window feature which removes the jfwid.Please suggest me how i can handle this issue.
I believe the ClientWindow feature is disabled by default. The following JavaDoc details the behavior:
http://docs.oracle.com/javaee/7/api/javax/faces/lifecycle/ClientWindow.html#CLIENT_WINDOW_MODE_PARAM_NAME
Also I'm not sure why disableClientWindow would be expected on a p:commandButton(h:commandButton) as that is a POST request whereas the p:button(h:button) would be a GET request.
Looking at the vld docs for the h:commandButton you'll see there is not a disableClientWindow attribute but on the h:button there is.
I've tried disable it to all application on web.xml, but without any success. I tried the follow:
<context-param>
<param-name>javax.faces.lifecycle.ClientWindow.CLIENT_WINDOW_MODE_PARAM_NAME</param-name>
<param-value>none</param-value>
</context-param>
The only way that I got it to work was using it on code before a redirect, for example:
FacesContext.getCurrentInstance().getExternalContext().getClientWindow().disableClientWindowRenderMode(FacesContext.getCurrentInstance());
return "/home?faces-redirect=true";
Or using it on own button or link:
<a jsf:disableClientWindow="true" target="_blank" jsf:outcome="go_to_anywhere?faces-redirect=true">GoToAnywhere</a>
Related
I'm trying to migrate an application from wildfly 9.0.1 to wildfly 10.1 and when I try to access the page I get this error.
The only component I could think of in my page related to it is a selectManyCheckbox maybe but I can't find anything that tries to render an "enable" string.
As it turns out it was a property set in my web.xml to blame:
<context-param>
<param-name>org.richfaces.enableControlSkinning</param-name>
<param-value>enable</param-value>
</context-param>
I'm migrating a JSF application from Spring Security 3.2 to 4.0.1. This version changes many default urls, for example the default login url to /login.
The application has its own login page (using JSF AJAX) and it is still displayed when calling /login, but all POST-Requests to this URL (and so all AJAX-Requests from the Login-Page) are captured by the UsernamePasswordAuthenticationFilter and that is trying to process the authentication, causing the request to get redirected to the loginform again.
After looking at the code this url seems to be hard-coded:
public UsernamePasswordAuthenticationFilter() {
super(new AntPathRequestMatcher("/login", "POST"));
}
So I have to disable this filter completely, or better, avoid it's creation. Can anybody point me how I can do it.
Changing my login page to another url is working, but is not the nice solution.
EDIT: I have created a Bugticket in Spring Security for this: https://jira.spring.io/browse/SEC-2992
EDIT 2: I've found another workaround: If I set the login-processing-url for the form-login to something unused it is working, but seems to be very hacky. There should be a way to disable it completely. Also it should be stated in the migration guide, I lost hours until I found this.
I am going to assume that you are trying to upgrade to Spring Security 4.0.0 (the latest available version is 4.0.1).
Spring Security 3.x used spring_security_login as the default login URL (source: official documentation). This could be set to a custom value as <security:form-login login-page="/login"> and mapped to a controller to render a custom page.
Spring Security 4.x has abandoned spring_security_login and switched to login as the default login URL (source: official Spring Security 4.x migration guide). Therefore, the URL login now goes to the default Spring Security infrastructure, that displays the default, auto-generated login page.
There was a bug in 4.0.0 due to which the default infrastructure was still getting used in cases where the URL /login was manually mapped to a custom controller method. This bug has been fixed in 4.0.1. Do try upgrading to Spring Security 4.0.1 to see if you can use /login as the login URL.
It looks like you could call setFilterProcessesUrl(String) (or, equivalently, setRequiresAuthenticationRequestMatcher(RequestMatcher)) to override the default of /login.
I used JSF 2.2 Mojarra and the Session Scope.
After some time the Session Scope is delete or something else. If I go back to the login page and login again I have a new Session Scope and everything worked again.
If I worked on the web application the Session Scope is not lost, and I have no problem. So I think it must be lost after some time if I don't use the web application.
Any idea how can I automatically go back to the login page if I lost the session scope?
To expect this first your state saving method should be set to server like below
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
After this you should have a session time out like below in your web.xml
<session-config>
<session-timeout>20</session-timeout>
</session-config>
If you are idle for more than 20 minutes and if try to make any request from the page then you would see a exception stack trace of ViewExpiredException. Now to redirect to the login page on this you have a have the following config in web.xml
<error-page>
<exception-type>javax.faces.application.ViewExpiredException</exception-type>
<location>your login page path</location>
<error-page>
This would work if you make a non ajax request from the page after session time out. Now to make it to work on click of a an ajax button it requires special exception handler for exceptions on ajax requests. you can use <pe:ajaxErrorHandler> from primefaces extension library.
To use this you need to have following in your faces-config.xml
<application>
<el-resolver> org.primefaces.application.exceptionhandler.PrimeExceptionHandlerELResolver</el-resolver>
</application>
<factory>
<exception-handler-factory>org.primefaces.application.exceptionhandler.PrimeExceptionHandlerFactory</exception-handler-factory>
</factory>
And primefaces extension namespace xmlns:pe="http://primefaces.org/ui/extensions".
Now in your page just have <pe:ajaxErrorHandler /> in your page. This would navigate to login page on ajax button click in a page after session time out.
For automatic navigation to login page on time out you can use <p:idleMonitor> Something like
<p:idleMonitor timeout="6000" onidle="idleDialog.show()" />
Please have a look at this question for correct implementation of idle monitor
Timeout via idlemonitor (primefaces)
If you are using icefaces please visit the following link
JSF Session timeout and auto redirect to login page without user intraction eventhough Ajax push is active
You can also use omnifaces FullAjaxExceptionHandler, Please google for this.
Hope this helps!!!
I met a problem, I want to set the tag of security-constraint according to my configuration file dynamically, but I can't do it. So I hope tag in web.xml can be dynamically generated or written outside web.xml. Thanks a lot for your help!
I think your question could be related to this one. However, if you were working with Servlet 3.0 spec, you could try the approach of programmatically adding and configuring security for the servlet, as shown here.
In the web.xml file, I'm trying to specify an error page as follows.
<error-page>
<location>/WEB-INF/jsp/admin/ErrorPage.jsp</location>
</error-page>
I expect it to go without an error code according to Servlet 3.0 but it doesn't. I have to explicitly specify an appropriate error code for it to work something like the following.
<error-page>
<description>Missing page</description>
<error-code>404</error-code>
<location>/WEB-INF/jsp/admin/ErrorPage.jsp</location>
</error-page>
Why doesn't the former approach work with Servlet 3.0?
I have upgraded NetBeans 7.2.1. It supports Apache Tomcat 7.0.27.0 which has Servlet 3.0 API.
By the way, I have disabled the HTTP Monitor as it raises the following warning.
MonitorFilter::WARNING: the monitor filter must be the first filter in
the chain.
It happened when I used Spring security in my application and it was reported as a jira issue.
Have a look at this post. I never personally made this
<error-page>
<location>/WEB-INF/jsp/admin/ErrorPage.jsp</location>
</error-page>
working on Tomcat 7, as for the bug described in the link I gave you. I don't know if Apache solved it in later version of Tomcat, but I doubt.
My previous statement was probably wrong. Digging a bit, I found this: https://issues.apache.org/bugzilla/show_bug.cgi?id=52135 and the problem should have been solved in Tomcat 7.0.29, so your only solution is to update to post-29 version.
Here: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html, in the changelog for version 7.0.29 you can read why there was such an issue:
Add support for a default error page to be defined in web.xml by
defining an error page with just a nested location element. It appears
this feature was intended to be included in the Servlet 3.0
specification but was accidently left out. (markt)