Persistent Cookies

For what I could observe, Xojo Web Sessions aren’t real Sessions, I mean, Users Sessions. They are more like “Current connection Session”; connection drops (like closing the laptop lid and moving to another room), connections rises, zap, the “session” is gone, another one is created, and your app, variables, etc are gone too. I’m not aware of other system having such behavior… I really dislike it.

That said, this behavior lead me to another problem: Cookies. All I found about cookies in Xojo web is tied to this “connection session”, and they seem ephemeral as I could understand from docs. Connection breaks,connection timeout occurs, all your app cookies are gone with it.

Cookies are made to store persistent data for your app, you store it with limited time set and for a “path”, an authorization for a segment of your app, and retrieve it at any time, between sessions, after server reboots, etc since that cookie lifetime is still valid.

I can’t see an App.Cookies, something proper to use Cookies as they are intended, in Xojo Web. Am I missing something?

I need to read some startup cookies shared by multiple connections to control real user sessions.

1 Like

I believe the issue you are facing is because you do not set an expiration date for the cookies.

If you don’t provide an expiration date, your cookie will expire when the session ends. If you do provide an expiration date, the cookie will expire as late as the provided expiration date because browsers can decide to discard cookies before they expire.
WebCookieManager — Xojo documentation

I have a WebApp where I set a unique user_uuid and store it in a Cookie. When the users comes back to the WebApp (through another session), the user_uuid is correctly retrieved.

1 Like

My problem is based on how poor the docs are in the intro. They made it look like it was impossible. There was no mention to expiration or whatever.

https://documentation.xojo.com/topics/application_structure/web/introduction.html#getting-started-application-structure-web-introduction-cookies

Thank you. Knowing that someone made it already is a great plus.

Agreed.
https://tracker.xojo.com/xojoinc/xojo/-/issues/71874

Sadly, it’s private.

Sorry, I made it private. Didn’t mean too.

1 Like

They should use more hyperlinks at key places too as:


This is how you set an ephemeral cookie (vanishes with the session) value:

Session.Cookies.Set(“UserName”, “BobRoberts”)

You can set persistent cookies adding a future expiration time as (Retain it for 1 month and 6 hours):

Session.Cookies.Set(“UserName”, “BobRoberts”, DateTime.Now.AddInterval(0,1,0,6))

I also had trouble with cookies - they disappeared after the session closed. Two potential issues not mentioned above:

  1. Don’t reference Session.Cookies from any event procedure or method in the Session. Better to put this in a module somewhere else.
  2. If your website is secure, you need to secure the cookie. But this won’t work while debugging. I use this:
#if DebugBuild
  Session.Cookies.Set(CookieName, CookieValue, ExpDateTime)
#else
  Session.Cookies.Set(CookieName, CookieValue, ExpDateTime, "", "", True)   ' this sets secure mode cookie
#endif

Could you please elaborate on item #1?
I don’t know of any issues off the top of my head but would like to be informed.

As for #2:

Session.Cookies.Set(CookieName, CookieValue, ExpDateTime, "", "", Session.Secure)

Information on Session.Secure

I’ve updated the documentation to explain this but we have branched so it will appear in the 2023r1 docs.

re: Don’t reference Session.Cookies from any event procedure or method in the Session
From an old post here: Cookies not readable in Session Open
Current documentation link: WebSession — Xojo documentation

Thanks for mentioning Session.Secure, I didn’t know about that one.

1 Like

In my initial tests, reading a Persistent Cookie seems working just ok in a Session.Opening event.
Logically an Ephemeral one wouldn’t, as it vanishes to start a new session.

1 Like

I agree it should work from Session.Opening if you use Self.Cookies and not Session.Cookies. But I haven’t confirmed this.

What I found strange was if I used Session.Cookies I was unable to read cookies. No error, just returned an empty string.

I had. At least in a tiny test sample.

I have a strong feeling that both, in a Session event context, are the same Websession.Cookies, unless in a bugged Xojo Web of the past they diverged.

Is this relevant to the issue?

To refer to the current Session from within the Session object, use Self instead of Session as the prefix, especially in the Opening event because it may return Nil.

https://documentation.xojo.com/api/web/session.html#session

1 Like

That deserves a technical explanation. Having a “random” behavior usually is not an acceptable pattern. It seems a documented bug. In a EventY() of an ObjectX, self should always be ObjectX. Looks like ObjectZ is calling ObjectX.EventY(self = ObjectZ) ? Who is ObjectZ? And when ObjectZ appears, who is ObjectX (that should be the real self, Session in this context)? Looks like some kind of bugged mix of Self and Sender? Please @Ricardo_Cruz , if you can explain if this still occurs nowadays, not a bug from the past, the WHY must be documented, and acceptable. If my object has a property mmm=1, showing mmm or self.mmm should show 1 always.

I tried to find a difference, but in all my trials, using the Session.Opening, Session.Identifier and Self.Identifier matched. I couldn’t replicate the bug pointed in the docs. Was it fixed?

What I noticed is that Xojo does some jugglery with syntactic sugaring, and Session, at the root level, seems a module, and the real Session object is really Session.Session, and maybe in the past they made things confuse while spraying that sugar and just thrown some lines in the docs while trying to fix it?

i think Session() is a method as well as a Class.

That’s probably why you need Self. I’m not sure under the hood but i think they made it harder than needed. So you need a WebSessionContext while you can also call App.SessionAt(index) causing much confusion. So then there would be too many ways to get a session.