Welcome back!
I agree with what you are saying. I guess I am thinking only in my own space
of using in an Intranet application where the environment is a little more
controlled. This is also why I suggest it be optional.
Regards
Scott Warren
Ocom Software
... Exceeding Quality.....
web | ocom.com.au
> -----Original Message-----
> From: joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx
> [mailto:joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx]
> Sent: Friday, 29 December 2006 9:44 AM
> To: Scott Warren
> Cc: 'Klotz, Leigh';
> chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> Subject: Re: [Chiba-developer] timingissuesin
> XFormsSessionManager/DefaultXFormsSessionManager
>
> Guys,
>
> finally i'm back from holydays and back to the topic...
>
> Scott Warren wrote:
> > I have been watching this thread, I have another use-case. What if the
> user
> > has a form on the screen, simply to View the information? Clicks the OK
> > button as they do because that's what they have always done. Which in
> > general cases will do a submit. But the session has timed-out because
> they
> > didn't actually change anything, nor did they even touch an input field.
> >
> > I am for a Ping and I agree with Leigh's idea. How about when the user
> > leaves an input field a ping is sent and the ping timer is reset. If a
> > timeout of X seconds has occurred since the last ping the timer will
> send an
> > automatic ping. Then the ping is reset again. I hope this is clear.
> Yes, i think this is largely the same as Leigh proposed and i'd like to
> emphasize again that i accept the validity of your use cases but still i
> have a problem with such a ping.
>
> In a friendly world ... no problem.
>
> But in the attempt to mature and harden Chiba for real-world operation
> i'm worried about the security implications - it's simply dead-easy to
> run a DoS attack against the server, bring it down and produce a heap
> space overflow.
>
> Btw, i consider the fact that Chiba Web is a pure server-side XForms
> engine as an advantage but it must be leveraged. Having full validation
> features on the server-side and all opportunities to prevent
> vulnerabilities like cross-site scripting or SQL injection beats any
> client-side XForms implementation (how good it may ever be) at least for
> serious multi-user applications which have security concerns.
>
> IMHO the session management must not be steered by the client. This
> moves the control to the client and gives too much power away.
>
> So, as a result of these thoughts (please contradict me) the only option
> seems to be to apply a smarter approach to session management which
> still leaves the server in control but still satisfies the mentioned use
> cases. I'm currently lacking ideas besides the one already mentioned:
> making sessions persistable, allowing sessions timeouts to be
> configurable (in certain reasonable dimensions) per form and
> re-initializing a previously persisted session transparently for the
> user. Of course and unfortunately this is much harder to implement than
> the proposed solution.
>
> I'm really interested in your thoughts and hope maybe there are other
> options that at least can serve as a migration path to the full solution.
>
> Joern
> >
> > Unfortunately I just have too much work at the moment to spend time on
> the
> > serialization of sessions which I also believe will be useful.
> >
> > Regards
> >
> >
> > Scott Warren
> > Ocom Software
> > ... Exceeding Quality.....
> > web | ocom.com.au
> >
> >> -----Original Message-----
> >> From:
> >> chiba-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> >> [mailto:chiba-
> >> developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx] On
> >> Behalf Of Klotz, Leigh
> >> Sent: Tuesday, 19 December 2006 11:33 AM
> >> To: joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx
> >> Cc: chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> >> Subject: Re: [Chiba-developer] timingissuesin
> >> XFormsSessionManager/DefaultXFormsSessionManager
> >>
> >> Sorry I meant DWR, not DRM ;-)
> >>
> >> I believe the easy case is the one I solved, and shouldn't require any
> >> additional markup.
> >> - The user is interacting with the form,
> >> - but @incremental isn't set,
> >> - and the form controls themselves don't happen to require any DWR
> >> interactions,
> >> - so they don't send anything
> >> - so the Chiba session doesn't know the user is there.
> >> Therefore, eventually it times out.
> >>
> >> So I propose a simple change in the behavior of the Flux JavaScript:
> >>
> >> - The user is interacting with the form,
> >> - but @incremental isn't set,
> >> - and the form controls themselves don't happen to require any DWR
> >> interactions,
> >> - so the onfocus/onblur/onclick/onkeydown handlers on the form controls
> >> check the time of the last DWR action
> >> - and if the last DWR interaction was more than a minute ago, it sends
> a
> >> keepalive.
> >> - so the Chiba session *knows* the user is there.
> >> Therefore, it doesn't time out.
> >>
> >> This doesn't fix timeouts for the StandardServlet (non-Flux).
> >>
> >> Leigh.
> >>
> >>
> >> -----Original Message-----
> >> From: joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx
> >> [mailto:joern.turner-S0/GAf8tV78@xxxxxxxxxxxxxxxx]
> >> Sent: Monday, December 18, 2006 4:22 PM
> >> To: Klotz, Leigh
> >> Cc: Adam Retter;
> >> chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> >> Subject: Re: [Chiba-developer] timing issuesin
> >> XFormsSessionManager/DefaultXFormsSessionManager
> >>
> >> Klotz, Leigh wrote:
> >>> We found that typing in a textarea could lead to session timeout, so
> >> we
> >>> put in a ping feature every minute or so as long as there is activity
> >> on
> >>> controls. @incremental satisfies it already. Probably the check
> >> should
> >>> have been done on most recent DRM call rather than at the ping and
> >> event
> >>> level, to have the optimal elimination of unnecessary pings.
> >> Leigh,
> >>
> >> yes, your use case has been heart and accepted as a general problem and
> >> i've searched for generalizing an approach to such situations.
> >>
> >> I've come up with several thoughts/ideas:
> >> - first, we've implemented a 'pulse' feature for any form by adding a
> >> <chiba:keepalive pulse="900"/>
> >>
> >> element as first child under the root of the document. This allows to
> >> add a ping to every form that might use it. The problem with this
> >> approach is that it effectively disables server-side session management
> >> and should be used with caution. This way a forms session would never
> >> expire unless the user leaves in a defined way.
> >>
> >> - second, Scott brought up the serialization topic again. If Chiba
> >> XFormsSessions could be persisted after their timeout has happened and
> >> deserialized when the user comes back then the problem of forms timing
> >> out would become pointless. This is a larger change though Scott has
> >> done some nice groundworks in the right direction.
> >>
> >> - third i've thought about adding an chiba element to allow the author
> >> to set the XFormsSession timeout per form. Different forms have very
> >> different usage situations and a global timeout for every form might
> not
> >>
> >> be appropriate. Together with the second point (so you can steer how
> >> long your form lives before you've to take the cost of
> >> (de)serialization) this looks like the most promising solution to me.
> >>
> >> But what exactly do you mean by 'the check should have been done on
> most
> >>
> >> recent DRM call ..."? Of course i'm interested in further options and
> >> ideas to address this issue.
> >>
> >>
> >>> Without some sort of ping feature, users working on forms with big
> >> text
> >>> areas lose their work and are unhappy.
> >>>
> >>> -----Original Message-----
> >>> From:
> >>> chiba-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> >>> [mailto:chiba-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx]
> >>> On Behalf Of
> >>> Joern Turner
> >>> Sent: Friday, December 15, 2006 1:39 PM
> >>> To: Adam Retter
> >>> Cc: chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> >>> Subject: Re: [Chiba-developer] timing issuesin
> >>> XFormsSessionManager/DefaultXFormsSessionManager
> >>>
> >>> Adam Retter wrote:
> >>>> 1) XFomsSessionManager.setTimeout() the parameter is named
> >>> milliseconds,
> >>>> but the javadoc says seconds - which is it?
> >>> millis
> >>>
> >>>> 2) XFormsSessionManager.setInterval() the parameter is not named and
> >>>> there is no javadoc, is this seconds or milliseconds?
> >>>>
> >>>> 3) DefaultXFormsSessionManager.DEFAULT_TIMEOUT is set to 5000, with
> >>> the
> >>>> comment that its 5 minutes, however if this is in milliseconds that
> >>>> would be 5 seconds, if its in seconds it should be 300 not 5000.
> >>> ok, should be fixed
> >>>
> >>>> 4) DefaultXFormsSessionManager.interval is set as 1500, the parameter
> >>> of
> >>>> DefaultXFormsSessionManager.setInterval() implies that this is in
> >>>> milliseconds. So this would be 1.5 seconds, this seems very short?
> >>> right. This value might still be present from testing. This feature
> >>> actually is not very stable. Though working i didn't intend to
> >>> communicate it's existence ;) since the whole issue has been
> >> clarified.
> >>> The context here is the requirement to have sessions that don't expire
> >>> because of long intervals between values updates through the user.
> >> This
> >>> pulse feature was one attempt to solve that but it does not convince
> >> me
> >>> yet. The better solution here would be to have persistent sessions
> >> that
> >>> are persisted when there's risk to loose data through session expiry.
> >>>
> >>> To cut it short if there are not strong arguments to keep the pulse
> >>> feature we'll probably remove it again.
> >>>> 5) ChibaServlet.createXFormsSession() line 443:
> >>>> manager.setTimeout(1000 * 30); // 1 minute session lifetime
> >>>> Assuming that setTimeout() should be set in milliseconds, this set's
> >>> it
> >>>> to 30 seconds, not 1 minute as the comment describes.
> >>>>
> >>>> I would be happy to tidy up and fix these issues is someone can
> >>> clarify
> >>>> whats what...
> >>>>
> >>>> Thanks
> >>>>
> >>>>
> >>>
> >>>
> >> -----------------------------------------------------------------------
> -
> >>> -
> >>> Take Surveys. Earn Cash. Influence the Future of IT
> >>> Join SourceForge.net's Techsay panel and you'll get the chance to
> >> share
> >>> your
> >>> opinions on IT & business topics through brief surveys - and earn cash
> >>>
> >>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> >>> V
> >>> _______________________________________________
> >>> Chiba-developer mailing list
> >>> Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> >>> https://lists.sourceforge.net/lists/listinfo/chiba-developer
> >>>
> >>
> >> -----------------------------------------------------------------------
> --
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the chance to share
> >> your
> >> opinions on IT & business topics through brief surveys - and earn cash
> >>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >> _______________________________________________
> >> Chiba-developer mailing list
> >> Chiba-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> >> https://lists.sourceforge.net/lists/listinfo/chiba-developer
> >
> >
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
|
