Re: Implementing a session timeout counter

Hi Joachim,

On 08/05/2018 09:21, [email protected] wrote:
> The problems I see are not JavaScript timouts and stuff to make this
> thing count down. My problem is more related to how to keep the counter
> in sync with the server side timeout. I am not talking about msecs or
> such, but the fact that there are at least two things that reset the
> counter on the server side and that needs to be communicated to the
> client: one is every standard callback processing, the other is Ajax
> (and maybe in some applications we also have WebSockets involved).

> I guess the best way to communicate the fact that the counter is back to
> (say) 40 minutes is to use an HTTP Header that gets added to every
> response, be it from some normal callback or Ajax callback. Do you guys
> agree?
> If we agree so far, we'd have to add some javascript code to all our
> rendered pages that ask for that Header and reset/restart the countdown.
> In case of complete-re-renders of a page this is probably something in
> the load script, right?

> For Ajax, I'd use JQuery's .ajaxComplete() to do the same. I guess there
> is some way to access the headers and restart the timer.

> Am I on the right track? Has anybody done this before? Maybe there
> already is something available in Seaside?
I don't know of something existing in Seaside, other than JQAjaxSetup,
for which you could define a global "ajaxSuccess" event handler that
will be invoked after each of your ajax requests (sucessful or not).

I use that (start/stop/error) global handlers to show "loading" messages
or errors if something went wrong (including a session a timeout).

You should check whether the response is valid or not there.

When there is a full page request, you set that on a regular <script> or
`addLoadScript:` script.

> The next wish on our list would be a button that a user can press in
> order to keep the session alive without doing anything else. This, I
> think, would be easy by just sending a little ajax request to the server
> that does basically nothing. Everything else is implemented already when
> the above-mentioned steps are done... right?
A non-op ajax callback would fulfill that given the above was implemented.
> Bonus question: Should the http header be filled with the end datetime
> of the session or the last tiome it was reset and to which value? In the
> former case, how can I determine it on the server, given I don't want to
> have the session timeout time in two places or a global
I'd send the timeout in delta (seconds/millis) in order to avoid clock
offsets between the client and the server and compute the "last request
timestamp" based on the local clock, and then you can implement a
countdown clock locally based on that.

If needed, you could add a RequestFilter that adds such header.

In the case of websockets if you're using some sort of message "types",
you can have a special message to set the new timeout on the client.


Regards,

-- 
Esteban A. Maringolo
_______________________________________________
seaside mailing list
[email protected]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside