I have implemented the answer of this question: Session timeout and ViewExpiredException handling on JSF/PrimeFaces ajax request
When an AJAX request is done and there is a ViewExpiredException it renders my session expired page, which has a link to go to the login page. But when you login again it shows me this:
<partial-response id="j_id1">
<changes>
<update id="j_id1:javax.faces.ViewState:0">
<![CDATA[ -4163638607746842558:-2237921975175382496 ]]>
</update>
</changes>
</partial-response>
When I press F5 the normal HTML content is shown. Why is this happening and how can I solve it?
Edit: To clarify, after logging in it takes me to the same page where the ViewExpiredException occurred.
Related
I am working on a JSF application which redirect to another application then do some processing there and redirect back. Issue is when I use JSF application URL as
http://172.20.1.175:8080/app_path/page.xhtml
and redirect back to the URL,
http://172.20.1.175:8080/app_path/page1.xhtml
then I am getting xml page on the browser like following
<partial-response>
<changes>
<update id="javax.faces.ViewState">
<![CDATA[
-------
]]>
<![CDATA[
--------
]]>
</update>
</changes>
</partial-response>
but if I use http://localhost:8080/app_path/page.xhtml and redirect back to the URL http://172.20.1.175:8080/app_path/page1.xhtml it's working fine (172.20.1.175 is my IP address). I am using spring security for authorization.
I am trying to figure out the reason for this behavior. Any ideas?
Thanks,
Lakmal
How to prevent user from going back to the login page
after successful login using back button of browser in spring security 3.2 and jsf
need custom filters? how to do ...
help me
​Thanks
for the same problem, I disabled button back in browser:
<SCRIPT type="text/javascript">
window.history.forward();
function noBack() { window.history.forward(); }
</SCRIPT>
Put this function in your welcome page.
I am having issues with the Omnifaces FullAjaxExceptionHandler (http://showcase.omnifaces.org/exceptionhandlers/FullAjaxExceptionHandler). It does not redirect to the specified error page after the session is invalidated.
I have the following in my faces-config:
<factory>
<exception-handler-factory>org.omnifaces.exceptionhandler.FullAjaxExceptionHandlerFactory</exception-handler-factory>
</factory>
And the following in my web.xml:
<error-page>
<exception-type>javax.faces.application.ViewExpiredException</exception-type>
<location>/pages/error/viewExpired.html</location>
</error-page>
After I invalidate the session, from a user's perspective nothing seems to happen. The application is just 'dead'. In my console I see the following Ajax request:
A POST to the original facelet page with a response code of 302
a GET to the login page with a code 200 (but nothing happens because it's requested via Ajax)
I am running MyFaces 2.1.10, Primefaces 3.5, Primefaces Extension 0.6.3 & Omnifaces 1.4.1 on WebLogic 12c
Could anyone help me in the right direction? How do I get the FullAjaxExeptionHandler to work properly?
Thanks
A POST to the original facelet page with a response code of 302
This is not right. A redirect on a JSF ajax request must have a response code of 200 with a special XML response with a <redirect> element with target URL in its url attribute.
This thus indicates that you manually used HttpServletResponse#sendRedirect() somewhere long before JSF has the chance to deal with ViewExpiredException.
Perhaps you've somewhere a servlet filter which checks some session attribute and sends a redirect based on its presence/state? That filter should then be manipulated based on the following answer: JSF Filter not redirecting After Initial Redirect in order to recognize JSF ajax requests and return a special XML response instead of a 302 response.
E.g.
if ("partial/ajax".equals(request.getHeader("Faces-Request"))) {
response.setContentType("text/xml");
response.getWriter()
.append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>")
.printf("<partial-response><redirect url=\"%s\"></redirect></partial-response>", loginURL);
} else {
response.sendRedirect(loginURL);
}
This all is completely unrelated to the FullAjaxExceptionHandler. JSF didn't have any chance to throw a ViewExpiredException because you're already sending a redirect yourself beforehand.
I had this Google floodlight code on a secure page in one of the websites I maintain. This content is inside and iframe which in turn is inside :
<script type="text/javascript">
document.write ('<IFRAME src="https://fls.doubleclick.net/activityi;src=XXXXX;type=12312;cat=084;qty=1;cost=$iTotal;?" width="1" height="1" frameborder="1" style="display:none"
</IFRAME>')
</script>
recently IE issued a message stating the page has insecure content. Inspecting the page with fiddler I can see that now the Google server that receives the floodlights also sends back a javascript library:
"http://www.googleadservices.com/pagead/conversion.js"
which is causing the insecure content message.
Has this happened to you too? Any idea how to fix it?
I found a tag I didn't knew on doubleclick:
<img src="https://gan.doubleclick.net/gan_conversion?advid=K123456&oid=12345&amt=123.45" width=1 height=1>
but It's not very clear if it does the same thing.
Ideas?
In the corrosponding Google Floodlight activity, you'll want to check the box that says "Secure Servers Only (https)".
I have a requirement that a jsf page needs to be launched from a custom thin client in user browser (thin client does a http post). Since the jsf page may be invoked multiple times, I use a jsp to redirect to the jsf page with params on url. In jsp I do a session invalidation. The jsp code is below:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%#page session="true" %>
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
session.invalidate();
String outcome = request.getParameter("outcome");
String queryString = "outcome=" + outcome ;
response.sendRedirect("./faces/MyPage.jspx?" + queryString);
%>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"></meta>
<title>title here</title>
</head>
<body></body>
</html>
My jsf page uses mutiple drop down items with autoSubmit enabled. I set the params on session when the form first inits and then use it from there when an action button is ultimately clicked by user. Following is the code I use to get the param in jsf backing bean constructor:
FacesContext ctx = getFacesContext();
Map sessionState = ctx.getExternalContext().getSessionMap();
outcome = (String)sessionState.get("outcome");
if(outcome == null) //if not on session, get from url
outcome = (String)JSFUtils.getManagedBeanValue("param.outcome");
This way I can get the param even after multiple autoSubmits of drop downs.
My problem is that I cannot have parameters show up on browser address bar. I need a way so that the parameters can be passed to the jsp page. I cannot post direct to jsp from thin client since I need the jsf page to have a new session each time the client launches user browser. This is imp due to the above code snippet on how I use params in the jsf page.
Is there nay way to use a post when doing a sendRedirect so that I do not have to pass params on url? I cannot use forward since when an autoSubmit fires on jsf page, it causes the browser to refresh the jsp page instead.
Is there any better way to handle the jsf page itself so that I don't have to rely on storing params on session between successive autoSubmit events?
Since you invalidate the session, no, you cannot.
The only way would be putting it in the session scope. Why are you by the way invalidating the session on first request? This makes really no sense.
Unrelated to your actual problem, doing sendRedirect() in a scriptlet instead of a Filter and having a bunch of HTML in the same JSP page is receipt for big trouble. Do not write raw Java code in JSP files, you don't want to have that. Java code belongs in Java classes. Use taglibs/EL in JSP only.
No. Because sendRedirect send the web-browser/client a 302 with the new location and according to the following it will usually be a GET, no matter what the original request was.
According to HTTP/1.1 RFC 2616 http://www.ietf.org/rfc/rfc2616.txt:
If the 302 status code is received in response to a request other
than GET or HEAD, **the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user**, since this might
change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, ***most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method***. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
Maybe playing carefully with ajax can get you something.
Update: Then again, as user: BalusC pointed out, you can redirect by manually setting the headers, as in:
response.setStatus(307);
response.setHeader("Location", "http://google.com");