@sandro Who are you? My message was telling @Matteo that nobody needs his condescending judgment after he said to me “I don’t feel the need for being so overly dramatic over something that is in the not near future.”. Everyone in this thread realizes that this is a very real technical issue that Cloudflare support even confirmed to me privately they are working on solving.
You are the one who is rude, by defending your buddies instead of honoring legitimate and paying customers.
Or not – keep doing what you’re doing! I have contacted Cloudflare about you with screenshots before you delete this and other’s messages again.
I did not even address your issue and I dont really care either to be honest. What I do care about though is a civilised and respectful tone here on the community and you clearly failed in this context. Let alone your posting buddy.
I did not delete a single of your messages, but as you seem to refer to the unrelated and trolling messages I moved to a separate thread (not even those were deleted), you seem to want to associate with that person and his behaviour. I am not sure what kind of light that is supposed to cast on you though.
Thanks @user8963. Fanboys galore indeed! Not to worry though: if this issue isn’t solved in a week, we and MANY OTHERS are leaving Cloudflare (just at the time of their IPO) – it ain’t the only shop in town.
@david33 two weeks ago after my reply to you, I addressed this with the Cloudflare staff that can handle this topic. I was told that Cloudflare is addressing it.
It feels like a simple solution, but I believe it needs to go through security scrutiny and engineering implementation.
Is this issue indeed being worked on internally, @cloonan? ETA?
Engineering-wise, there is a little bit of non-trivial code to write to support incompatible browsers, so I can empathize with Cloudflare taking some time to get it right.
However, this is now affecting users of the beta version of the most popular web browser. Developers are especially impacted, and our company is seeing it firsthand with hundreds of developers that use our mission-critical Cloudflare Workers endpoints.
We’ve said multiple times how critical this issue is. In early 2020 when Google flips the switch on Chrome, it can blow up millions of websites (e.g. Intercom’s customers’ websites).
Cloudflare support initially said they will fix it by early December, and now they just said “we don’t have an ETA”.
This is how Cloudflare treats their paying customers.
@cloonan can you please provide insight into why this isn’t resolved yet?
50% of Chrome beta users are experiencing broken pages/resources/applications due to rejected Cloudflare cookies. We’re longtime customers of Cloudflare’s Business plan, and this is especially impacting our third party developers and bottom lines. The lack of appropriate action and transparency on this major issue isn’t the Cloudflare I know.
A cookie associated with a cross-site resource at https://cloudflareinsights.com/ was set without the `SameSite` attribute. Next is the browser insights domain
How about SameSite=Lax? Will that work? Or do you need None? Personally I prefix mine with __Secure- & use SameSite=Strict. But that’s me… and I COULDN’T BE HAPPIER THAT CLOUDFLARE HAS BEGUN USING =Lax as it’s far better then no restrictions at all.
I’m not much into cookies and the underlying tech of cms/wordpress/framework/whatever.
It came to my attention recently, working with Elementor plugin on my Wordpress CMS, that it might be using CloudFlare as a security service somehow, as i have not been installing any plugin from CloudFlare myself (At least not to my knowledge ;-). Nevermind, this is not the main reason for this reachout attempt!
It’s just meant as a heads up! And the concerned staff is probably already aware!
In any case Mozilla Chrome is reporting this warning on my site: (Image extraction attached)
You might want to implement this setting, if it at all matters!? Sorry ahead! I didn’t have time to check if this has already been submitted and are unaware of the propper forum channel to submit this info, as i am not qualified (As Bruce would say
With the hope this could in any way serve as a helpful resource for the duly concerned…
__cflb (load balance) is steel without SameSite attribute.
And my site works inside a iframe on a different domain. __cflb and __cfduid cookies on my domain are treated as third party cookie by browser now (Chrome Beta v80). So the browser send requests without these cookies. I need these cookies would be set: “SameSite=None; secure”. My site works only in https.
Is there a way to force this?
If no, a configuration to do this would be appreciate. And we have few days to do it.
My application cookies are OK to Chrome changes (v80). To re-force my needs about it, I did these changes on WebConfig (IIS). Only to remember: My web application runs inside an iFrame on a different domain.
Only Cloudflare cookies are blocked now. On each response, Cloudflare try to set the cookies but Chrome doesn’t accept it.
Let me know if change SameSite and secure on cookies will be possible on future (when). If not, I have to find an alternative to use load ballance with session affinity and the analytics (ex: unique visitors will be very wrong).
Which means there were no SameSite attribute specified for __cfduid cookie by Cloudflare.
It is okay to me is it takes time from Cloudflare to resolve the issue.
But I don’t understand why it was said that issue is resolved when it actually is not resolved.