Shared Cookies not Removable

I access multiple Xojo web apps from my one computer (macOS). If I set a cookie in one Xojo Web app to represent a UUID eg
Session.Cookies.Set("UUID", "ABC123", YearFromNowDate)

then the cookie is set properly and is accessible for each Xojo web app using:
UUID = Session.Cookies.Value("UUID")

If I remove the Cookie in one of the other Xojo web apps ie
Session.Cookies.Remove("UUID")

then the Cookie appears blank if I immediately try to retrieve it.

BUT if I log out of my Session and reconnect the removed UUID Cookie is back with the previous value! Is this correct?

Can a Cookie only be Removed by its originating Xojo Web App? How can I set and/or remove a Cookie that is cross-Xojo Web App compatible?

Cookie Remove not removing.xojo_binary_project.zip (10.5 KB)

This may be a Xojo bug, but it could also be browser-specific. I just read this article April King — Handling Cookies is a Minefield which discusses all the weird edge cases in cookie handling.

A related comment: Cookies are filled with weird gotchas and uncomfortable behavior that works 99.9... | Hacker News suggests that cookies with the same name, but different properties (domain, path…) may “shadow” each other.

When you call Session.Cookies.Remove(): are you using the exact same cookie name, domain, and path as when you called Session.Cookies.Set() ?

No, I have left them blank. Is it best practice to fill these? With what — Domain with the Application Identifier? and Path with ???

In Safari / Settings / Advanced, click the Show features for web developers checkbox.

Run your Xojo Web app in the IDE.
In Safari, from the Develop menu, open the Web Inspector, and click on Storage / Cookies.

(You can do a similar thing in other browsers such as Chrome)

You’ll see something like this which lists all the cookies for this domain.

This might help you see what’s going on.

Also, if you read the third answer here:

it suggests the proper way to delete a cookie:

Finally, to remove a cookie, the server returns a Set-Cookie header with an expiration date in the past. The server will be successful in removing the cookie only if the Path and the Domain attribute in the Set-Cookie header match the values used when the cookie was created.

I wonder if Xojo is doing this properly?

If not, you can probably work around it yourself:

  • don’t call Cookies.Remove()
  • instead call Cookies.Set() with a bogus value, and an expiration date in the past.

Your Xojo web apps are running on your computer?
If not, are all running on the same domain?
If not and they are running on different domains, do you want to delete a cookie for domainA from domainB?

I’m sorry but it was not clear to me.

1 Like

Another way to see what’s going on is to check the Network tab. Here’s an example of clicking a button which calls Session.Cookie.Remove()

From this, it looks as if Xojo is doing the “right thing” - deleting a cookie by setting its expiration date into the past.

I suspect @AlbertoD has the right idea - the answer depends on how you are running “multiple” webApps from the same device…

  • same domain, different paths, e.g. example.com/app1 , example.com/app2
  • different domains, e.g. app1.example.com , app2.example.com etc.

Thanks for the web link, it helped me understand what Domain and Path mean and I think I can leave them blank.
As per your advice, I have tried instead to set the Expiry date on the Cookie to be in the past, then delete it, but it still remains with the future date. Here is the code:

Var YearBeforeNowDate As DateTime = DateTime.Now.SubtractInterval(1) 'expire 1 year ago
Session.Cookies.Set(CookieName.Text, CookieValue.Text, YearBeforeNowDate)
Session.Cookies.Remove(CookieName.Text)

You can see the ExpiryDate as 2025 in Safari:

At the moment I have finished a Web App and am testing it before deployment on my host, so currently it is all on my one macOS computer ie 127.0.0.1. I keep aside a fake UUID cookie, plus the last UserID and ServerID to allow them to sign in via their password alone without having to fully sign in each time.
What was shocking was that the cookie values that return for these CookieNames were for another Xojo Web App, and I have been unable to remove them, nor get my new cookies to stick around after my Session ends.

Interestingly, if I try to manually reduce the Cookie date with the Safari Developer tool, the older date doesn’t get saved, instead Safari beeps.

You should be able to just delete them there. Right-click?

I’m quite certain that setting the domain to an empty string won’t be a supported condition, regardless of your actions. All the information I’ve come across indicates that it’s a mandatory parameter, and any results without it will be unpredictable.

However, if all the apps share a domain, you shouldn’t encounter any issues. Just make sure to exclude the subdomain.

example.com // this

www.example.com // not this

This is what I eventually did.

I think the reason I couldn’t remove the old Cookies is that I have asked Safari to stop third party tracking, so it seems to sandbox my new cookies to only last for that session and after that be discarded, plus stop me from removing/editing old cookies.

I will be using my domain from now on, but leaving the path blank.

1 Like

Also, there are some recent changes in Safari that makes testing these things difficult when working with cookies using the localhost / 127.0.0.1 hosts. Testing it on a real domain with HTTPS sometimes helps.