Atozed Forums

I am using Intraweb 15.6.1 with C++ Builder (Rad Studio 10.2.3).
I noticed that it is not possible to open IWForm2 from IWForm1 using Ajax if the ServerControler CookieOptions has the following settings:
1. SameSite=ssoNone
2. UseCookies=True

I have attached a demo.

I will prefer to be able to keep UseCookies=True to be sure that cookies are cleaned when the browser is closed!

UseCookies: Boolean; [Published, Read/Write]

Quote:When True, IntraWeb will use cookies to do all the session management, on the browser side. When SessionCookies is False, the cookies will be persistent, i.e. even if you close and reopen the browser, the cookie will be preserved. On the other hand, when UseCookies is True and SessionCookies is also True, IntraWeb will create HTTP session cookies which are not persistent, meaning that the session will be lost, on the browser side, when the browser is closed.

I just noticed that if UseCookies=false, html links like below are not working. When you click on the link, no action is performed!


Which obliges me to reverse SameSite=ssoLax!

But this can be a problem with Google Chrome coming updates!

UseCookies = True is the default and preferred way to configure the application. The option to set it to false is for very specific types of applications and should never be used in general.

Please notice that:

(a) UseCookies means exactly that, IW will make use of cookies to handle the session information.

(b) SessionCookies means a different thing. This means that the cookies are not persisted when the browser closes (not the browser tab, but the whole browser window).

These are different concepts.

SameSite = ssoNone in modern browsers requires the SECURE flag also set which means that this only works in HTTPS. This is not an IntraWeb limitation but that's how modern browsers enforce it. I suggest you stick with SameSite = ssoLax

Please have a look at this thread you responded to it yourself:

https://www.atozed.com/forums/thread-3994.html

If SameSite is not set to ssoNone this will create issues in future Chrome versions!

Yes, I remember that.

What I said is that SameSite = ssoNone must be used in order to have 3rd party or cross-site cookies, and that part remains true. What I said above is also true.

Browsers keep changing their requirements every single week, literally. As I said above, ssoNone requires SECURE attribute also set, otherwise it won't work anymore (meaning, it used to work a few months ago, but someone in W3C, Google, Mozilla Foundation, whatever, decided that now they want it to work and behave differently).

SECURE attribute requires HTTPS (it won't work in HTTP, another "standard" requirement).

Putting everything together we have: SameSite = ssoNone only works with SECURE + HTTPS.

Not even testing in localhost it won't work if using HTTP. Painful, I know, but we don't have any control over this.

I'll run your test application and see if there is something else at play, but everything that I responded before and now stands.

I tested the same settings on my live application with HTTPs connection and this is when I noticed the issue.
The test sample were built later.