Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
Sorry to bug you all again.. I am still seeking a clarification on above points.. if anyone can please enlighten me. Thanks. On Sat, Feb 15, 2014 at 1:29 AM, user 01 user...@gmail.com wrote: Can some one please clarify What is this attributes map otherwise really meant for? Is it to maintain JSF internal viewstate ? On Fri, Feb 14, 2014 at 1:31 AM, user 01 user...@gmail.com wrote: Thanks a lot Leonardo for the solution. Played somewhat with it, looks like it'll works for me. The data survives session destroys. What is this attributes map otherwise really meant for, to maintain JSF internal viewstate ? Is it safe for me to use it like that ? Looks like a hack infact:) I could use the attributes map to store values/ objects, can't I just use this map to store the viewscoped beans simply? On Thu, Feb 13, 2014 at 11:05 AM, Leonardo Uribe lu4...@gmail.comwrote: Hi In JSF 2.2 it was decided to store view scope beans always in session (take a look at the description of @ViewScoped annotation in the javadoc). But you can just call facesContext.getViewRoot() and use the attribute map. Just remember the values there must be Serializable or implement StateHolder. In my understanding, this was done in this way to support @PreDestroy annotation when the session is expired. regards, Leonardo Uribe 2014-02-12 23:28 GMT-05:00 user 01 user...@gmail.com: I'm using Myfaces 2.2 with Client-side state saving. I see that the ViewScoped beans data stored in viewmap is lost after the user session is destroyed. I came to know, not sure if it is correct, that this is the expected behavior but then what's the way to avoid view expired exceptions after session destroy? My problem is that I destroy the user session pretty quickly after some inactivity period(like after 20 minutes) but I want the viewscope data to survive even after that(when using client saving) so that when the user comes back after session destroy, he doesn't need to do a page refresh. I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. I think the internally used jsf viewstate is not lost, if I use client side state saving(as my pages still work), but then why are those viewscoped beans scoped that were also serialized to page along with the viewstate. If this the designed behavior, Is there any way I could make the view scoped data survive session expiration ?
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
It's just a map to add data - like ViewState. In JSF 2.0 and JSF 2.1, it was used to directly store the ViewScoped beans. Don't know about more internals. 2014-02-21 21:42 GMT+01:00 user 01 user...@gmail.com: Sorry to bug you all again.. I am still seeking a clarification on above points.. if anyone can please enlighten me. Thanks. On Sat, Feb 15, 2014 at 1:29 AM, user 01 user...@gmail.com wrote: Can some one please clarify What is this attributes map otherwise really meant for? Is it to maintain JSF internal viewstate ? On Fri, Feb 14, 2014 at 1:31 AM, user 01 user...@gmail.com wrote: Thanks a lot Leonardo for the solution. Played somewhat with it, looks like it'll works for me. The data survives session destroys. What is this attributes map otherwise really meant for, to maintain JSF internal viewstate ? Is it safe for me to use it like that ? Looks like a hack infact:) I could use the attributes map to store values/ objects, can't I just use this map to store the viewscoped beans simply? On Thu, Feb 13, 2014 at 11:05 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi In JSF 2.2 it was decided to store view scope beans always in session (take a look at the description of @ViewScoped annotation in the javadoc). But you can just call facesContext.getViewRoot() and use the attribute map. Just remember the values there must be Serializable or implement StateHolder. In my understanding, this was done in this way to support @PreDestroy annotation when the session is expired. regards, Leonardo Uribe 2014-02-12 23:28 GMT-05:00 user 01 user...@gmail.com: I'm using Myfaces 2.2 with Client-side state saving. I see that the ViewScoped beans data stored in viewmap is lost after the user session is destroyed. I came to know, not sure if it is correct, that this is the expected behavior but then what's the way to avoid view expired exceptions after session destroy? My problem is that I destroy the user session pretty quickly after some inactivity period(like after 20 minutes) but I want the viewscope data to survive even after that(when using client saving) so that when the user comes back after session destroy, he doesn't need to do a page refresh. I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. I think the internally used jsf viewstate is not lost, if I use client side state saving(as my pages still work), but then why are those viewscoped beans scoped that were also serialized to page along with the viewstate. If this the designed behavior, Is there any way I could make the view scoped data survive session expiration ?
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
Can some one please clarify What is this attributes map otherwise really meant for? Is it to maintain JSF internal viewstate ? On Fri, Feb 14, 2014 at 1:31 AM, user 01 user...@gmail.com wrote: Thanks a lot Leonardo for the solution. Played somewhat with it, looks like it'll works for me. The data survives session destroys. What is this attributes map otherwise really meant for, to maintain JSF internal viewstate ? Is it safe for me to use it like that ? Looks like a hack infact:) I could use the attributes map to store values/ objects, can't I just use this map to store the viewscoped beans simply? On Thu, Feb 13, 2014 at 11:05 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi In JSF 2.2 it was decided to store view scope beans always in session (take a look at the description of @ViewScoped annotation in the javadoc). But you can just call facesContext.getViewRoot() and use the attribute map. Just remember the values there must be Serializable or implement StateHolder. In my understanding, this was done in this way to support @PreDestroy annotation when the session is expired. regards, Leonardo Uribe 2014-02-12 23:28 GMT-05:00 user 01 user...@gmail.com: I'm using Myfaces 2.2 with Client-side state saving. I see that the ViewScoped beans data stored in viewmap is lost after the user session is destroyed. I came to know, not sure if it is correct, that this is the expected behavior but then what's the way to avoid view expired exceptions after session destroy? My problem is that I destroy the user session pretty quickly after some inactivity period(like after 20 minutes) but I want the viewscope data to survive even after that(when using client saving) so that when the user comes back after session destroy, he doesn't need to do a page refresh. I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. I think the internally used jsf viewstate is not lost, if I use client side state saving(as my pages still work), but then why are those viewscoped beans scoped that were also serialized to page along with the viewstate. If this the designed behavior, Is there any way I could make the view scoped data survive session expiration ?
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. You could just add an ajax poll components and ping the server all 5 minutes - so the session will only be destroyed if all tabs from your application are closed.
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
Good suggestion Thomas, For myself I would need this: 1 Hour: Keep session alive with p:poll 1 Hour: Render p:idleMonitor instead and warn for activity and session destroy in x minutes. The switch to a idleMonitor would require that you check the submitted request parameters and this way know if poll component triggered the request or the user. A plain p:poll is unacceptable for our system for security reasons. On 13 February 2014 09:26, Thomas Andraschko andraschko.tho...@gmail.comwrote: I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. You could just add an ajax poll components and ping the server all 5 minutes - so the session will only be destroyed if all tabs from your application are closed.
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
Karl, p:poll introduces security concerns? Please elaborate/clarify. Thanks. On Feb 13, 2014 3:39 AM, Karl Kildén karl.kil...@gmail.com wrote: Good suggestion Thomas, For myself I would need this: 1 Hour: Keep session alive with p:poll 1 Hour: Render p:idleMonitor instead and warn for activity and session destroy in x minutes. The switch to a idleMonitor would require that you check the submitted request parameters and this way know if poll component triggered the request or the user. A plain p:poll is unacceptable for our system for security reasons. On 13 February 2014 09:26, Thomas Andraschko andraschko.tho...@gmail.com wrote: I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. You could just add an ajax poll components and ping the server all 5 minutes - so the session will only be destroyed if all tabs from your application are closed.
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
It's just that if you just do p:poll every five minutes they are never logged out from activity. This has actually caused us to fail a security screening in the past. 1. Users use security system before leaving office, forgets to logout and the PC does not lock from inactivity either 2. In the middle of the night a burglar breaks in and has direct access to system because p:poll has kept stuff warm for him 3. Lose Customer To clarify our users might just leave with computer logged on and system logged on so session timeout is essential. In general they actually want really short session timeouts but the tricky part is that for some pages they want 1H or similar. When they work on those pages they can't just lose the session so we warn them in advance. Might be enough to just use p:idleMonitor. Our solution is homemade because we don't have primefaces in that product so I was brainstorming when I mentioned it. For us it's DWR that keeps the session alive but in the future it will be p:push. TLDR: If you use p:poll don't forget that users may forget to logout and p:poll will disable session timeout. On 13 February 2014 12:52, Howard W. Smith, Jr. smithh032...@gmail.comwrote: Karl, p:poll introduces security concerns? Please elaborate/clarify. Thanks. On Feb 13, 2014 3:39 AM, Karl Kildén karl.kil...@gmail.com wrote: Good suggestion Thomas, For myself I would need this: 1 Hour: Keep session alive with p:poll 1 Hour: Render p:idleMonitor instead and warn for activity and session destroy in x minutes. The switch to a idleMonitor would require that you check the submitted request parameters and this way know if poll component triggered the request or the user. A plain p:poll is unacceptable for our system for security reasons. On 13 February 2014 09:26, Thomas Andraschko andraschko.tho...@gmail.com wrote: I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. You could just add an ajax poll components and ping the server all 5 minutes - so the session will only be destroyed if all tabs from your application are closed.
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
Very interesting, Karl, and thanks for the clarification! +1 at the responses on this thread. They interested me, because for security implementation in my app is - 15 minutes session expiration (web.xml) - meta refresh tag in head tag that redirects page to view expired 'page' (got that concept/code from BalusC on stackoverflow.com) but some months ago, an enduser requested a 'keep-alive session' requirement on a page that will 'not' end his session while he using the 'payroll' page to do his work. He did not want to have to keep logging in, and having to make filter selection via p:calendar begin/end dates of payroll period, and then scroll down to job/employee that was last marked as paid. So, i found some keep-alive-session code (by BalusC on stackoverflow.com) and refactored app/page a bit to keep the session alive until he logs out of the app or until he navigates to another page. well, now that you all are talking about this, this reminds me of a recent discussion on tomcat list about (re)designing webapp to allow enduser to login and resume his work. I like that concept, and that might be the best approach to address 'security concerns'. There would be no need to p:poll, p:push, etc... just to keep the session alive or to push a message to client to 'end' the session and logout user (sometime ago, i developed some p:push + java bean code that did that, but not using that implementation in the app). polling to keep session alive seems to be the easiest way to 'satisfy' the enduser, but definitely not the most-secure, as you said earlier. this discussion may motivate me to refactor my app a bit, accordingly. thank you all! On Thu, Feb 13, 2014 at 7:07 AM, Karl Kildén karl.kil...@gmail.com wrote: It's just that if you just do p:poll every five minutes they are never logged out from activity. This has actually caused us to fail a security screening in the past. 1. Users use security system before leaving office, forgets to logout and the PC does not lock from inactivity either 2. In the middle of the night a burglar breaks in and has direct access to system because p:poll has kept stuff warm for him 3. Lose Customer To clarify our users might just leave with computer logged on and system logged on so session timeout is essential. In general they actually want really short session timeouts but the tricky part is that for some pages they want 1H or similar. When they work on those pages they can't just lose the session so we warn them in advance. Might be enough to just use p:idleMonitor. Our solution is homemade because we don't have primefaces in that product so I was brainstorming when I mentioned it. For us it's DWR that keeps the session alive but in the future it will be p:push. TLDR: If you use p:poll don't forget that users may forget to logout and p:poll will disable session timeout. On 13 February 2014 12:52, Howard W. Smith, Jr. smithh032...@gmail.com wrote: Karl, p:poll introduces security concerns? Please elaborate/clarify. Thanks. On Feb 13, 2014 3:39 AM, Karl Kildén karl.kil...@gmail.com wrote: Good suggestion Thomas, For myself I would need this: 1 Hour: Keep session alive with p:poll 1 Hour: Render p:idleMonitor instead and warn for activity and session destroy in x minutes. The switch to a idleMonitor would require that you check the submitted request parameters and this way know if poll component triggered the request or the user. A plain p:poll is unacceptable for our system for security reasons. On 13 February 2014 09:26, Thomas Andraschko andraschko.tho...@gmail.com wrote: I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. You could just add an ajax poll components and ping the server all 5 minutes - so the session will only be destroyed if all tabs from your application are closed.
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
Thanks a lot Leonardo for the solution. Played somewhat with it, looks like it'll works for me. The data survives session destroys. What is this attributes map otherwise really meant for, to maintain JSF internal viewstate ? Is it safe for me to use it like that ? Looks like a hack infact:) I could use the attributes map to store values/ objects, can't I just use this map to store the viewscoped beans simply? On Thu, Feb 13, 2014 at 11:05 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi In JSF 2.2 it was decided to store view scope beans always in session (take a look at the description of @ViewScoped annotation in the javadoc). But you can just call facesContext.getViewRoot() and use the attribute map. Just remember the values there must be Serializable or implement StateHolder. In my understanding, this was done in this way to support @PreDestroy annotation when the session is expired. regards, Leonardo Uribe 2014-02-12 23:28 GMT-05:00 user 01 user...@gmail.com: I'm using Myfaces 2.2 with Client-side state saving. I see that the ViewScoped beans data stored in viewmap is lost after the user session is destroyed. I came to know, not sure if it is correct, that this is the expected behavior but then what's the way to avoid view expired exceptions after session destroy? My problem is that I destroy the user session pretty quickly after some inactivity period(like after 20 minutes) but I want the viewscope data to survive even after that(when using client saving) so that when the user comes back after session destroy, he doesn't need to do a page refresh. I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. I think the internally used jsf viewstate is not lost, if I use client side state saving(as my pages still work), but then why are those viewscoped beans scoped that were also serialized to page along with the viewstate. If this the designed behavior, Is there any way I could make the view scoped data survive session expiration ?
Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
Hi In JSF 2.2 it was decided to store view scope beans always in session (take a look at the description of @ViewScoped annotation in the javadoc). But you can just call facesContext.getViewRoot() and use the attribute map. Just remember the values there must be Serializable or implement StateHolder. In my understanding, this was done in this way to support @PreDestroy annotation when the session is expired. regards, Leonardo Uribe 2014-02-12 23:28 GMT-05:00 user 01 user...@gmail.com: I'm using Myfaces 2.2 with Client-side state saving. I see that the ViewScoped beans data stored in viewmap is lost after the user session is destroyed. I came to know, not sure if it is correct, that this is the expected behavior but then what's the way to avoid view expired exceptions after session destroy? My problem is that I destroy the user session pretty quickly after some inactivity period(like after 20 minutes) but I want the viewscope data to survive even after that(when using client saving) so that when the user comes back after session destroy, he doesn't need to do a page refresh. I dont know why how this is so implemented but It is very normal that the user may be busy reading some section of website or be away for 20 minutes, as he comes back interacts with opened pages, how would I make that work without the state ? I think this is a common requirement for any public websites. I think the internally used jsf viewstate is not lost, if I use client side state saving(as my pages still work), but then why are those viewscoped beans scoped that were also serialized to page along with the viewstate. If this the designed behavior, Is there any way I could make the view scoped data survive session expiration ?
