Hi Joachim,

On 08/05/2018 09:21, jtuchel@objektfabrik.de 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,