Web 2.0 App development, lifecycle and session management

I made a simple empty app that shows the session id, and at every refresh I see a new session id, that’s the first time I see such behavior. So I don’t understand how Xojo web works comparing with other web environments.
Do we have a technical Xojo Web Intro doc or video?
Do we have something explaining the basics of Xojo Web 2.0 app development, life cycle of apps, sessions or Xojo proprietary views on those subjects, like how the session management and app continuity works? Those kind of things.

Compared to what?

PHP Sessions for example.

So bringing the user right back to where they were is more complicated in Xojo than in PHP because of a number of things, including (but not limited to) the fact that your UI code is written on top of the Xojo framework that’s on top of Bootstrap and jQuery. We’re not talking about simple text fields here, but complex controls with lots of attributes, all of which would need to be restored.

So yes, you set a cookie in PHP and you can echo it back to yourself, but that’s not the same as restoring all of the pages and controls on those pages back to the state they were in before the user refreshed the browser. We’ll get there, we just haven’t worked out all of the edge cases.


Well, I think that I, and basically all newbies, need an “Intro to Xojo Web app basics and session management” in the current form. Please, have a 5-15min tech intro video done someday (Or Paul, with your guidance).


Great news! Well not really news, as you said it already a few times, but great that Xojo is still on this.

Hold on, you are expected to regenerate the session id in PHP when the user wishes to execute a critical function at very minimum…

The security recommendations for PHP, advocate that you do change the session id on a regular basis…

PHP takes care of this all, automatically. Every time a new session begins, it’s a new session id. While the session is going on, it’s maintained. Once the timeout occurs, you will need to log in again (supposing that you made a system identifying users in their sessions), gain a new session (with a new id), and start over. You don’t lose your session and session variables on simple events like connection hiccups, or refreshes.
At every request to connect to a session ( session_start(); ), if you still in a valid session time, your current session is reconnected, and your current session id still valid and consistent with your last access. Your session data the same. If such session_start() occurs after a timeout ( or after a session_destroy() ), a new session will be started and all of your session content on the server from the last session will be lost.

To be fair, the Xojo framework does all of this too. The part you’re not considering is the state of the front end.

Imagine you had an elaborate front end for your app, that is, one that you don’t recreate from scratch every time a user connects to it. Now you need to maintain state on both sides and have a way of syncing the two.

Now imagine that the user does refresh their browser. Now you’ve got all this state info on the server but none of the corresponding state data on the user’s browser. That’s the problem we have to solve.

My answer was just to explain a bit how things work in a basic level for PHP for James (if necessary). Not taking Xojo in consideration at that moment. I still want to know how’s the best approach to write a simple session based app mimicking a desktop app, keeping a session alive for, let’s say, 10 minutes after the last interaction, resisting to a bit of connection instability like using a 4g mobile, those things. As I said, a video explaining a proposition on how to design a small demo like this with 2 parallel sessions, a “log in”, data entry and listbox, the settings involved, the “how to handle” known problems (like connection instabilities), best practices, caveats, current limitations, etc. Would be great.

This is considered a security weakness today. I’m doing a postmortem on a hacked PHP site at the moment. A failure to recycle the session ids during a user session and a failure to force a fresh login before critical operations can be bad news these days.

This is part of the reason we’re taking our time with this. Security is very important and we’re trying to do everything we can on this front.

1 Like

That’s a so bad design that I don’t how and why someone did it. Every ID should not repeat, as it is by default.

Well, to avoid a new login, a session must be hyper-persisted, survives to almost anything, even closing the browser and reopening the app, and that can lead to hijacking flaws if bad designed. Simple measures can protect 99% of the cases from hijacking, like checking if the IP of the user requesting the session data comes from the same IP from the original creator.

1 Like

Sorry, it should read: regenerate no recycle.

This, if you;re a PHP guy: PHP: session_regenerate_id - Manual

I know the process. It should be advisable the “change” the ID in the case of a long time using it. The process can get you troubles if not well done, and can be unstable in unstable networks, it can cause orphan residual sessions until destroyed in the future that can also be potentially exploited. But for simple cases, simple apps, where you WANT that someone reenters its credentials, and start over (with a new session), for SECURITY REASONS if they let the system alone for 10-30min, it’s mostly unnecessary.

All of what you are asking for is already there.

For tracking user activity, there’s a property named


Which causes the Session.TimedOut event to fire when the user has been idle for the specified number of seconds (no mouse, touch or keyboard access). This was also available in API 1.

Unstable connections are handled automatically. Browsers will show a temporary overlay if the server can’t be reached and will automatically reconnect to the same session if it returns within 5 tries, usually 5 seconds. After that, the browser automatically disconnects from the app, requiring a new session to be created. This two phase system is new in API 2. In the old system the user was not warned when the app’s connection was unstable and could end up losing data because they continued to work.


Thanks. But you still owe us a “Multi user, multi-window, concurrent sessions practices intro using Xojo Web” demo-tutorial. :smile:


I never offered, nor promised such a thing.

Sure, kind of joking as usual. That would be just a great contribution from Xojo to Xojo to prove the concept and teach. Never implied something to you as a person.

1 Like

Please? :slight_smile: