myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
Subject Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?
Date Thu, 13 Feb 2014 13:30:47 GMT
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.kilden@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. <smithh032772@gmail.com
> >wrote:
>
> > Karl, p:poll introduces security concerns? Please elaborate/clarify.
> > Thanks.
> > On Feb 13, 2014 3:39 AM, "Karl Kildén" <karl.kilden@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.thomas@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.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message