Same problem even by adding res.header("Set-Cookie", "HttpOnly;Secure;SameSite=None"); to my server it seems something similar needs to be added on Google's where they are serving https://apis.google.com/js/api.js

Using:
Chrome Version 77.0.3865.90 on MacOS Mojave

Same problem and also signIn method on auth instance from gapi.auth2.getAuthInstance() has stopped working once I enabled this flag in current version of Chrome (Win10, 77.0.3865.120). Can anything be done about this or is this something that should be fixed on Google side?

Guys, do anyone has any update on this? With chrome 78 signIn suddenly stopped working, I can't really ask users to go into chrome://flags and disable something.
Also, I read the chromestatus links again, and I still think this should be enabled by default only in chrome 80, what happened?

cc @grant @bochunz

Will look into this Monday and report a bug to the team when I can reproduce. 🙂
EDIT: Added internal bug b/143761058 and reported to the team. I will update this GitHub issue if there are updates.

If you interested in a production site which is affected for sure, go to wish.com and try to login with google. Again, it is working fine if you disable those flags.

Sorry for being hasty there, but I can't believe it is affecting only us. Any update?

@grant said he will report this bug to the team. It might not last long before it's getting fixed...
I found many apps having the same problem, but it concerns only a minority of users using the last version of chrome (cf canary deployment).

@grant when disabling the following flags on chrome the login works

For me it was enough to disable 'SameSite by default cookies'.

Do you guys know if this is a bug in this lib, or Chrome 78 accidentally enabled this flag 2 releases earlier?

After successfully integrating Google Calendar API using gapi library yesterday, I saw my Chrome was out of date.

After updating to v78, the integration stopped working - Sign in popup showed, I could 'sign in' but after the popup closed, nothing happened in the app. No errors though!

3 hours into figuring out what I changed in my codebase, I came across this thread - turns out the 3 flags set to disabled make it work fine again.

Of course, there are warnings about it in the console, but they mention it's due to be changed in FUTURE RELEASE.

I believe this was shipped accidently in v78, however the warnings are not errors because they are yet to be updated as it was meant to ship in later version.

@grant did you have time to look at it?
Your help would be really appreciated on this one 🤗

As I am still not sure whose fault is this and what is the exact issue I really don't want to rant or anything, but we decided to remove google login at this point. Don't get me wrong, it was planned to do something about the warning, but as this was only a warning to get ready this was totally unexpected. 19 days passed since the original report, you could easily say that forget this method, or something, but this lack of information is totally disappointing.

I assure you this is being looked at. There were updates today internally.

I updated that comment 3 days ago before the weekend. I've increased the priority of the internal issue.

This is also affecting our login for beta channel users. When can we expect Google services to be compatible with Chrome changes?

The team wanted me to give this update:

1. SameSite Updates: https://www.chromium.org/updates/same-site
   • This has the status and roadmap of the SameSite attribute.
2. Google is going to show a warning message to users to ask them to either move to Chrome Stable or turn off the flags.

@grant I am on chrome stable, I have that flag turned on by default on chrome stable, never ever installed canary/chromium or any dev version, and this stuff is broken since chrome 78 stable.

@steveetm That doesn't sound possible based on the timeline of when we enabled things. Are you running Chrome with --enable-experimental-web-platform-features? That would include the SameSite features in 78, though we removed them from that flag in 80.

@chlily1 it is possible, but hard to tell as when I ran into this problem manually switched flags to see if anything helps. But also got reports from end-users. What is sure for me it was working with Chrome 77 stable and got broken with Chrome 78, without change any flags between the update. Even if it is related with experimental-web-platform-features I think Chrome shouldn't tell me a warning that it will be enabled in the future when that flags is enabled(due a bug or planned change). It should throw warning it is enabled now because SameSite setting is defaults to true. But in that case this is a bug in Chrome.

Anyways, your response makes sense and I have no more questions about this, but I still feel there were some kind of chaos as it required more than a month to figure out exactly what is going on.

@steveetm I understand your frustration, and we've heard that feedback from others too.

We have recently updated the console messages to differentiate between warnings and actual blocking, by either saying "A future release of Chrome will..." or "It has been blocked because..." depending on the feature state. That is available in Chrome 80, and has been backported to Chrome 78, so you should see the new phrasing if your version is at least 78.0.3904.108.

I think this conversation lost track of the original issue reported. Google API assets, in how they are served by Google, are not in compliant with Google Chrome present (warning) or future (blocking). Users on stable un-tampered versions of Chrome are being warned by Google about something Google is doing.

Is it agreed that we're waiting for googleapis.com / accounts.google.com to begin serving SameSite cookies?

We are now 10 days away from stable.

Is there an update or should we start preparing for mayhem?

We are now 10 days away from stable.

Is there an update or should we start preparing for mayhem?

No mayhem. Chrome 79 stable will still have this feature disabled by default. Chrome 80 will have it enabled by default. Chrome 80 will be released around Feb 4.

References:
https://www.chromium.org/updates/same-site
https://chromestatus.com/features/schedule

Specifically, pay attention to the launch timeline (i.e., the three date bullet points) on https://www.chromium.org/updates/same-site . Notice that stable users are unaffected until Feb 4, 2020.

Ah, the main point to note is this got enabled even in 78 stable mostly due to:

* Unless you have explicitly activated them via chrome://flags, or unless you are running Chrome with the --enable-experimental-web-platform-features flag.

"Experimental Web Platform features" flag being enabled. In that case, I don't think this change is impacting our customers (unless they tamper with the flags) that much as us devs.

Hi all,
Are there any lasting concerns that I should communicate to the team? The team has mentioned that this issue should be resolved as of now.

@grant nope just waiting for Chrome 80 to start blocking Google API.

@grant still not working for me on Chrome MacOS 79.0.3945.79 (Official Build) (64-bit)
but canary is working on Chrome MacOS 81.0.3992.4 (Official Build) canary (64-bit)

@sergentj unnecessary warnings aren't harmless to developer experience.

Sounds like we have the same issue, the google translate API is causing issues in dev tools in regards to cookie security, but I can't seem to figure out a way to configure the cookie to satisfy Chrome's standards.

I'll be watching this issue and hoping that the translate API gets updated so we aren't ignoring the errors that dev tools reports.

I was going to upvote the reply that said Chrome is actively rejecting these cookies, because it definitely is (depending on how chrome://flags is configured, anyway -- I had to disable samesite cookies for it to ignore it).

any of you have any news of this problem? how much longer do we have to wait?

Disabling samesite cookies is not really going to help those of us who have client users scattered all over the place, is it? I don't control the browser or settings for users. Besides, my site doesn't, on it's own, even use 'cookies' -- I don't use or allow a Google or Facebook login (or any other type of 3rd-party login) to my site. I'm unsure why anyone would use that anyway, but that's another topic for another thread. So this thing is completely ridiculous as far as my site is concerned. Just venting ...

All the comments are quite interesting. I have a GAS web app and it doesn't run in Chrome! that's hilarious! Also, I wonder why the thread is closed when the issue has not been resolved... my app works fine in Firefox but for how long? this is quite frustrating...

This error now appears in Firefox 80.0.1.

Any update on this? I'm unable to use authentication because of this error.

I have an issue with the setting cookie too.
So we have rails api + react app on FE. I'm setting cookie on the backend with httpOnly: true and secure so cookie has to be written on backend app cookie storage but it is not. Even when I disable all 3 flags that are mentioned above, it doesn't work. Any thoughts?

Seems to still be broken in Chrome 85 on Android. Disabling "SameSite by default Cookies" fixes the issue.

Is there any expectation that this will work, or is there an alternative to gapi that is more actively maintained?

Somehow after uninstalling and reinstalling Chrome I now have version 80, and everything works as expected.. Don't know how to update again to 85 to confirm its still broken for me.

Sad that is issue is marked closed...!! Why is it closed. So many issues with samesite=none in spite of marking secure.

I am having the same problem. I do not understand why it is rejecting these cookies when I am putting these options with express.js

I have scoured the internet and I do not understand why this is happening. Can someone explain why the HttpOnly cookie is being rejected?

server.js

res.cookie('token', token,   { 
    domain: 'https://127.0.0.1:3000',
    path : "/endpoint",
    maxAge : 24 * 60 * 60 * 7, // 7 days
    httpOnly: true,
    secure: true,
    sameSite : "none"
});

And this is the Response Header that is being set

Chrome Network Tab Headers

Set-Cookie: token="somestring"; Max-Age=604; Domain=https://127.0.0.1:3000; Path=/endpoint; Expires=Sat, 24 Oct 2020 03:56:54 GMT; HttpOnly; Secure; SameSite=None

And this is the error code that I am getting

Chrome Network Tab Exclamation Point Error

this set cookie was blocked because its domain attribute was invalid with regards to the current host url

I was finally able to get this to work by omitting the Domain attribute using Express.js and Node.

It is also noteworthy that I am serving the website on https://127.0.0.1:3000 and I have enabled self-signed certificates so chrome won't throw an SSL error. (e.g. I am developing over https locally)

res.cookie('token', token,   { 
   path : "/api/v1/auth/fb/callback",
   maxAge : 24 * 60 * 60 * 7, // 7 days
   httpOnly: true,
   secure: true,
   sameSite : "none"
});

This is the response Header for the Set-Cookie Attribute

Set-Cookie: token=somestring; Max-Age=604; Path=/endpoint/of/request; Expires=Mon, 26 Oct 2020 18:29:32 GMT; HttpOnly; Secure; SameSite=None

Shout out to Lily Chen @ chromium for helping me solve this issue. I really appreciate it.

Wow this is 12 November 2020 and I am facing the same issue with React JS react-google-login library. I am using Microsoft Edge and the warning seems to persist. Here is my code:

<GoogleLogin 
                                        clientId ={jsonData.clientId}
                                        buttonText = {"Login"}
                                        onSuccess = {(response) => this.responseGoogle(response,this.props)}
                                        onFailure = {this.responseGoogle}
                                        cookiePolicy = {"single_host_origin"}
                                        isSignedIn = {true}
                                />

Does anyone got some solution for the same? Is it fine to ignore this warning? Will it affect my production website in any way?

Here is the warning message I get:

Because a cookie's SameSite attribute was not set or is invalid, it defaults to SameSite=Lax, which prevents the cookie from being sent in a cross-site request. This behavior protects user data from accidentally leaking to third parties and cross-site request forgery.

Resolve this issue by updating the attributes of the cookie:
Specify SameSite=None and Secure if the cookie should be sent in cross-site requests. This enables third-party use.
Specify SameSite=Strict or SameSite=Lax if the cookie should not be sent in cross-site requests

Hi,

My understanding is that it's a known issue that some Google Accounts cookies (e.g. SID) generate this warning, but it's safely ignorable. They are emitting the old-style cookies still for backwards compatibility reasons which are too complex to go into here. They also issue newer cookies which have the proper SameSite attributes.

If other cookies that aren't from Google Accounts in your application generate this warning it might be more serious.

@sedhha did you solve it? I have the same issue and apparently it blocks sign in from working

@akdu12 unfortunately no. For now, I am just ignoring it... as everyone said but not sure what will be it's impact.

Any update on this? It's been almost 2 years..

Same here, we still use google translate and it's still showing up for the google translate related cookies....

bump ....
Why this closed....
bump !

bump ....
Why this closed....
bump !

Because if you haven't figured it out by now, you're not going to figure it out at all.

bump ....
Why this closed....
bump !

Because if you haven't figured it out by now, you're not going to figure it out at all.

lolz k thanks

Name Domain & Path
jenkins-timestamper-offset localhost/
_ga localhost/
_gid localhost/
OTZ www.google.com/
SID .google.com/
HSID .google.com/
SSID .google.com/
APISID .google.com/
SAPISID .google.com/
S .google.com/
UULE www.google.com/
SIDCC .google.com/
SID .google.com.vn/
HSID .google.com.vn/
SSID .google.com.vn/
APISID .google.com.vn/
SAPISID .google.com.vn/
cppo .facebook.com/

May I ask what does it mean? Is it a question? an error? Or a response?

I ran into this issue a while back when trying to figure out why my cookies wouldn't set in Chrome despite working no Firefox. Here is what I figured out:

If you are running your client-side and server on an http connection, you do not need to set the SameSite or Secure attribute.
The SameSite attribute will default to Lax and cookies will work.

However, if you are running your client-side on an https connection, you need to make sure that your server is also running on an https connection.
In this case, set Secure to true and SameSite to None.
This should work!

名称 域和路径
詹金斯时间戳偏移量 本地主机/
_ga 本地主机/
_gid 本地主机/
OTZ www.google.com/
SID .google.com/
HSID .google.com/
SSID .google.com/
APISID .google.com/
SAPISID .google.com/
小号 .google.com/
优乐 www.google.com/
SIDCC .google.com/
SID .google.com.vn/
HSID .google.com.vn/
SSID .google.com.vn/
APISID .google.com.vn/
SAPISID .google.com.vn/
cppo .facebook.com/
Excuse me, do you know how to prevent these cookies? I'm working on privacy related projects. I don't know how to prevent cookie injection? Maybe you have some information or something