SetCookie Header didn't specify a "SameSite" attribute - Set Authentication Cookie Option

[jimmysafe]

Description

Hi,

I have created a simple React App (running on http://localhost:5173) that fetches data through WPGraphql.
I have installed wp-graphql-headless-login in order to get Social login features (Google and Facebook).

I am in the process of configuring the Google auth and i would like the wp-headless-login plugin to set the wp authentication cookie automatically on login success.

I am now able to login and create the logged in user automatically in wordpress.
The problem i am facing is that the wp auth cookie does not get set because it is lacking of the SameSite attribute.
I can see that the request tries to set the wp auth cookie but it does not get set.

Here is a screenshot:

There is no way for me within the plugin to change the SameSite attribute to none ?

here is my plugin configuration

.

Steps to reproduce

1. Install the plugin
2. add a Google provider along with CLIENT ID and CLIENT SECRET.
3. In the plugin Login Settings TURN ON all settings.
4. In the plugin Access Control Settings TURN ON Block unauthorized domains and Add ACAC.
5. Set the locally running react frontend url in the authorized domains.

Additional context

No response

Plugin Version

0.1.4

WordPress Version

6.4.2

WPGraphQL Version

1.19.0

Additional enviornmental details

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have disabled ALL plugins except for WPGraphQL and Headless Login for WPGraphQL

• Yes
• My issue is with a specific 3rd-party plugin.

[justlevine]

Hey @jimmysafe - thanks for bringing this up!

I've had exposing this as a setting on my long-term roadmap, but under the assumption that there was a core WP filter that already handled this. Turns outI was wrong, so it looks like this needs to be reprioritized.

that said:

• the plugin uses wp_authenticate(), so any drop-in for wp_set_auth_cookie() is probably compatible. I haven't tested, but I've seen this one referenced a few times.
• how exactly are your frontend and backend URLs configured? Do they match the WP HOME_URL and SITE_URL?. A lax cookie shouldn't be a problem on a subdomain iirc, but im also pretty sure WordPress takes those values into account when generating.

[jimmysafe]

Hey @justlevine thanks for the quick response!

i've just tried the plugin, but it does not seem to be working for my case ( define( 'WP_SAMESITE_COOKIE', 'None' ); does not work ).

My frontend and backend urls are configured as follow:

both the Site Address and Wordpress Address urls are the same, they should not be tho, as the frontend will be purely in react and will be hosted under another domain.

Btw if you have any other advice on how i could bypass this SameSite cookie issue it would be amazing!

[justlevine]

both the Site Address and Wordpress Address urls are the same, they should not be tho, as the frontend will be purely in react and will be hosted under another domain.

If you fix the site address, so it's pointing to http://localhost:5173, and re-save the permalinks and clear your cookies, do the newly generated cookies work?

[jimmysafe]

No, by changing to Wordpress Address to http://localhost:5173 it will actually break the whole wordpress installation as whenever i try to navigate to the wordpress admin dashboard i get this:

i have also tried to change the Site Address to http://localhost:5173 but the SameSite cookie issue still persists.

[jimmysafe]

@justlevine quick update, googling around i found a solution which finally worked: it's simply by installing this plugin.

Btw this should defo be a built in solution for WP-graphql-headless-login as it is such a nice and easy to use plugin!

I really thank you for the support and the amazing work!

[justlevine]

@jimmysafe happy to hear you found a drop-in workaround, and thanks so much for coming back to share!

I'll check it out as soon as I get a free minute - always better IMO to reinforce an existing solution than to reinvent the wheel 🤞

[alexookah]

I encountered the same issue! It would be awesome if this functionality were part of the plugin, eliminating the need for this workaround plugin.

Maybe an option could be to have the cookie not be session-based but saved with a defined expiration (e.g., default of 7 days). This would be useful for client-side solutions that can't securely save JWT tokens, as they are prone to XSS attacks.

what do you think @justlevine ?

[justlevine]

Love the idea @alexookah ! Im currently traveling but PRs are always welcome and I just followed up to your discord message, and will take a deeper look at prioritizing this once I'm back at my desk.