Keeping Web 2.0 alive

@Greg_O_Lone

Is there a “trick” to keep a user session alive when the user is leaving the app / browser?

My apps keep being alive all the time a user interacts with the app, but if I’m switching to do somethings else and I’m returning to the browser it is timing out, even if I’m putting the code into the open event in session:

session.UserTimeout = 0

My app is running as a service, but from the logs it doesn’t look like the app restarting or “crashing”, it is just the session disconnects if the browser view, which started the session, is losing focus. I’m currently selling this as a security feature (like with online banking), but I got the first response that in online banking you can refresh the time-out …

App.SessionTimeout ?

may be you could use a cookie to store the session informations, and the time the session ends in it, so that you can resume the session if the user comes back on the same browser ?

2 Likes

Yes, I read this. and I read somewhere the 0 means not to disconnect at all. But whatever value I’m using it doesn’t seem to have any effect :frowning:

Thank you, that sounds interesting but I’m not yet sure how to deal with it. it doesn’t seem to fire any event any longer, but yes perhaps I can deal with it if a user is trying to start the app again … I will play around with this.

No you cannot, it would create a major security issue. We use a state machine concept to do it. Once a customer provides the correct authentication and authorization details we reload the previous state within a given time frame and service availability. It is not dependent on the web session.

2 Likes

Yes, that was my fear, I actually enjoyed the disconnect the first time I noticed it. Even if storage of a the session in a cookie might work it will then involve the question when to really log out the User and how to guarantee that this cookie will be deleted. I don’t want to mess around with security. Customers will have to live with it.

I only wanted to ensure that I have not overlooked anything.

store a sessionID in the user cookie
save this sessionid on your server database, along with the limit time of this session

@Jean-Yves_Pochez That sounds good, but I’m struggling with how to load the session again with the WebApplication.SessionWithIdentifier command and more specifically how to load it “into” the current session. From the documentation it reads as if we would need to create a new session, but how will I tell my session variable which session has to be used? I think I’m missing something here.

sorry can’t say much more. that’s how I would do it, but I did not face the problem so did not investigate further !

1 Like

That’s not what UserTimeout is for. UserTimeout is about the amount of time the browser is idle (no key presses or mouse movement) before the Session.UserTimedout event fires. It’s just a way to detect if the user ward away and left the browser open like the way most banking sites do.

1 Like

You can’t load one session into another. Currently, if a users browser leaves the app and doesn’t come back quickly enough, the session and browser are no longer connected and cannot be reconnected. We do have plans for session resumption, but we’re not quite there yet.

1 Like

That will not fly. The only way to do something like this is relaible and maintainable way, is to have some kind of state machine concept.

When the user signs in you check what they were doing in the past session, if it was say in the last few minutes and it is still possible to restore the previous state then do so, otherwise ignore it.

For example if an online banking client drops a session during a stocks purchase. When the reconnect you would:

  • Check if the market is still open
  • Is the stock price still within the expected range
  • Do they still have sufficient funds etc…
    If all is good you put them back at the previous point.

This stuff is very time consuming to put together and test properly.

1 Like

That’s great, I mean having an official statement, now the customer has to wait ;-).

1 Like

I hear you. But anyway thank you for the answer. This is exactly not what I to Xojo to use for: rapid development ;-). But good news hearing from @Greg_O_Lone that they have future plans for keeping the session alive for a bit longer than currently.