SameSite Cookie Issues

continuing from here: Security Provider Issue with Server Side Redirection in SPA PHP

PROD: Wappler 3.9.1, PHP with SameSite attribute set to STRICT
DEV: Wappler 4.0.1, PHP with SameSite attribute set to STRICT and parent page and each route have security enforcer added.

login works via a server connect route - coming in from a third party domain. This works well in PROD but fails with a 302 right after server side redirection in DEV.

if we switch off security provider on parent - then login via server connect route works.
if we change SameSite attribute to NONE - then login via server connect route works.

but we cannot do either of these things.

so how can we make work SameSite: STRICT with security enforcer on the parent page of SPA with latest version of Wappler?

Bumping this! Server side redirect is still a problem we’ve had to change the app function to get around this for now! Would like to make this work.

Are the Server Connect API and the website on different domains? has link to is the Wappler project. is a server action route that validates the token, does a Wappler security login and then does server side redirection.
post this redirection, the user is somehow no longer logged in and we se unauth errors everywhere.

After the redirect you stay on the website? If you check the browser cookies, did it create a session cookie and optional an cookie for the security provider (only when remember was true with the login action). Check if the session cookie is correctly setup for the whole domain and if the same cookie is on the redirected page (you probably have to disable redirect to test if the cookie was set on the first page before the redirect).

yes, from the page is redirected (from server side) to (also part of the same Wappler project).

if we disable the server side redirection and just stop the steps on security login only - then all is good. if in a new tab i open the page - it shows as logged in and can access the app as expected.

but when server side redir is enabled, then user is no longer logged in on arriving on the next page.
between the security login step and the opening of the next page, the only step is the server side redirection step.

I’m not sure, but I think the problem is that the browser does not set any cookies when there is a redirect, and that causes the security provider to not work.

Since you are coming from a different domain there is no session active and no session cookie is stored, when you login it will store the user in the session and optional send a cookie to the browser in the response, however the cookies in the response are not handled on all browsers when it also has a redirect header and so no session cookie is written. Then on the next page it doesn’t have a session cookie and will create a new session, so you are no longer logged in.