Hi,
I have a question for the refresh of a website. Right now the current behavior is if I refresh the page i get sent back to the default page the SignIn page. My question is, how can i refresh the page and if the token is available stay on the current page but if the token is empty or expire go back to SignIn.
I have tried to look (and code) if there is an event that gets triggered with a page refresh but I do not see that on session or app objects. How can i do this? TIA.
The session resumption was one of the many failed promisses of Web2.
I think that your bes option is to save the user id, a lastVisited to have a limit when restoring, the relevant session data in a database and then use the WebSession.Opening to MANUALLY reconstruct the las session into the new one.
I always thought that the Session and State management had a flawed design in Xojo Web. When I tried Xojo Web in its early days the behavior was unlike any other tooling I’ve ever tried before, simply could not understand it, so I thought it was bugged. You could lose all the ongoing work (session vanishes) without recover just due a hiccup in the network, a refresh was the same, your work is gone.
I wish they can change it in the future, like a suspension with retries keeping the session during a network connection break, and session recover and page recover (state) in a refresh, during a small period (3 to 30 minutes). After the session timeout you should lose your work, not before.
Not sure how Xojo web works but you would think that they should be able to establish a session on the backend (server) and keep it alive in the frontend (app) for a certain amount of time. So does that mean that the session object in a web app is nothing but a misnomer? I mean if it does not work like a real session then what do you use it for? Could we not just do the same thing with the App object?
It is “a session” in the sense of separating you from other users and the global app, but… it is ultra-volatile. It does not support refreshes or connection breaks or it abandons your session and creates another one from zero.
Ok with all this info above, I still have some questions… is there an event that triggers when the web app refreshes? and is there a way to use sessionstorage or localstorage?
Something like event RefreshRequested ( which is does not exist now ) ?
When you say local storage, I guess you mean storing something on the browser itself.
Yes, that is possible.
Store:
https://documentation.xojo.com/api/web/websession.html#websession-recorddata
Read:
https://documentation.xojo.com/api/web/websession.html#websession-requestdata
Just to clarify, Xojo Web doesn’t refreshes the whole session anymore when there is a network hiccup, since 2022r2. Also if, for example, the user is on a mobile phone and the browser goes to the background, the session will be transparently restored as soon as the user comes back to this browser tab.
For persisting authentication, so the user can press on Refresh or just close and reopen the browser, you can use either Cookies (Session.Cookies.Set / Session.Cookies.Value) or the browser’s LocalStorage (through Session.RecordData / Session.RequestData).
In either case, when the user successfully logs in, you can generate and store some sort of token that you can verify later in the Session.Opening event.
What about Persistent Session ? That’s what users desires and use most.
Web systems usually keeps a “Session ID” in a Cookie created when the browser contacts the app for the first time and persisted by a Session Timeout time. If such cookie is still valid in a refresh, the browser page reconnects to the session and just continues, they do not recreate a session all the time. In such event, Xojo should offer tools so the user could decide the behavior through events like Page.SessionStart() [Cookie invalid, New session started] or Page.SessionRestart() [Session recovered and reconnected, rebuild the UI please] they (one or other) comes after the top level Session.Opening() [only if the Cookie was invalidated, New Session] Page.Opening() [Controls Created], and just continues. Users now know about the session reconnection (or having lost it and getting a blank one here) and refresh the UI as they prefer to continue, the easy way to handle it is just closing the session and moving to a start over page (login, sometimes), the hard way is repopulating fields using session contents (if possible) doing some state management and letting things to continue.
Something like that.
When a user will refresh the page, will it create a new session or not @Ricardo_Cruz ?
Since that would be a process requiring alot of cpu, memory etc to recreate the session. And some if not most visitors will refresh the page pretty often. If there is a way to overcome this process intensive tasks like session-renew and have it being restored (or instantly re-used) that would be the best for Xojo web i believe.
We’ve spoke about this internally in the past and we want to continue improving the session recovery, for cases where the user refreshes the current tab by mistake. Instead of cookies, which are shared between tabs, we’d probably like to use the SessionStorage instead, which is scoped and exists only inside that tab. Using cookies and forcing the session to be recovered even after closing the tab will break the current behavior.
Every browser tab has its own independent WebSession. A refresh will spawn a fresh new WebSession in that tab, at the moment.
Preparing the session isn’t that CPU intensive to be a big concern. But restoring it on refresh would be nice for user experience, yes.
So there isn’t the concept of user session? Currently every tab demands a login, for example, and an app instance can’t be distributed by several pages in different tabs? Like you inserting items in one tab and using the new items in another one (equivalent to windows in a Desktop app)?
People are used to “App instance” = Browser, “Windows of such app” = Tabs.
User session is App on Browser, not App on Tab.
I wouldn’t generalize that much. You can easily achieve that, if you want, with the included Xojo Web classes. If we force the framework to work that way, the developer will have to fight against it.
For example, think about a Xojo Web application as a POS (which I’ve seen a few already), with two independent touch screens, sharing the same browser. You definitely don’t want to share the items from one screen with the other one.
You have access to Cookies, LocalStorage and you’re able to iterate through the Sessions to update them in real time, only if you want.
Never seem something like your use case. We usually would open a new browser instance for another App instance / UI / new login.
Another browser instance will more than probably share the storage with the other instance by default.
If you want 2 instances of the same app in the same container you need to separate its data area as:
Starting 2 separated setups:
The same can be done with other browsers, pointing different “profiles”.
The point is that you have to unnecessary fight against the default browser behavior / framework if we change the behavior.
Ok, I just wanted to note that Xojo behavior is unusual, and users are fighting with it. Just it.
Have a nice day.
I truly appreciate talking with you Rick, don’t get me wrong.
The users can open Feature Requests if they are fighting against the framework, but in this case I already see the complains against changing the current behavior.
