I ran into such a problem.
When I run the application on my laptop (Linux/Ubuntu 18) in the developer console in the Chrome browser, I have this message
A cookie associated with a cross-site resource at
http://pubsub.rtschannel.com/ was set without the SameSite
attribute. A future release of Chrome will only deliver cookies with
cross-site requests if they are set with SameSite=None and Secure.
You can review cookies in developer tools under
Application>Storage>Cookies and see more details at
https://www.chromestatus.com/feature/5088147346030592 and
https://www.chromestatus.com/feature/5633521622188032.
On another laptop (Linux/Ubuntu 16) in the Chrome browser, when the application is launched locally, there is no such message.
I tried to find at least some information on this subject, but alas I couldn’t. The only thing I could find was the link inside the message that it was a browser bug and in Chrome version number 80 it should be fixed and this setting would be added by default.
Please tell me, does it depend on the browser settings, or can I somehow influence this message programmatically? Can I clean it somehow?
On the project, I use angularjs if this can help.
Thanks.
These warnings are purely informational at the moment and do not affect site functionality. This behaviour will not be enforced until Chrome 80 which is due to hit stable in Feb 2020.
You can simply turn off the messages by setting chrome://flags/#cookie-deprecation-messages to Disabled. However, that is purely affecting the display of the messages.
If the pubsub.rtschannel.com is not your domain, e.g. it's a third-party service you use, then it's that domain that will be responsible for updating the cookies.
If it is your domain, then you need to review the cookie usage and set an appropriate value for the SameSite attribute on the cookie. You can find more context and guidance on https://web.dev/samesite-cookies-explained.
Related
On the latest version of Chrome (Version 90.0.4430.85 on MacOS), I found that third-party cookies are disabled even though in my browser settings I checked "Allow all Cookies". I also tried adding the site to "Sites that can always use cookies" and checked "Including third-party cookies on this site", but it still doesn't seem to work. I'm accessing a course on LTI that requires third-party cookies. (The course is quite old so that might be an issue)
I'm getting this error:
Chrome Settings:
The reason I know this is because my other laptop has an earlier version of Chrome(around 80) and the cookies are working(the course loads), but it no longer works when I update my Chrome to the latest version.
When I tried in Safari, I'm able to allow third-party cookies by disabling "Prevent cross-website tracking", but I cannot find such settings in Chrome.
Any ideas on what I might try to be able to use third-party cookies on the latest version of Chrome? Also, why is it the case that this site functions in an earlier version of Chrome but not the latest? Thanks in advance.
Your browser settings for 3rd-party cookies look OK as far as testing by allowing all.
The issue may be with the LTI tool/app provider who is providing their product through Canvas and other LMS's - for example, if the LTI tool/app provider hasn't set their cookies with SameSite=None - sounds like you're suspecting that as far as course/app being older.
I think you can test this by temporarily disabling the same site requirement here: chrome://flags/#same-site-by-default-cookies
There are a few other decent testing tips from Chromium here.
If that's the issue and you still need to provide access quickly for a bunch of users, but can't wait for the LTI tool/app to be updated, you can usually update the LTI app/tool settings in Canvas to open it in a separate tab/window instead of as an iframe - e.g. these settings in Canvas.
Hope it works out!
I have set a cookie from an api and returned it as a response. But the latest version of chrome beta is not letting me to store the cookie. I have also set the SameSite="None" and Secure for considering third party cookies. But this is not getting stored.
Check chrome://settings/content/cookies. You want to ensure that:
"Allow sites to save and read cookie data (recommended)" is enabled
"Block third-party cookies" is disabled
Check the other settings there to ensure that the site is not on the "Block" list.
You should also check that you don't have any extensions that are affecting cookie behaviour. A quick way of generally testing this is to try in Incognito Mode or by creating a new Chrome profile.
How to solve SameSite attribute?
:1 A cookie associated with a cross-site resource at http://doubleclick.net/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.
same for google.com, linkedin, facebook.com, twitter.com. etc
Unable to add 'Samesite' attributes. What will be the best way to get this solve?
The reason why you are getting this warning is because you are using an external resource (like an image). In my case, I copied an image URL/Address online and included it into my project. I didn't save it in a folder, so I got that warning.
The way I solved it is simple: I just said it: download whatever file you are trying to access locally and that warning will disappear.
Hope this helps
My web client application is setting HTTP POST requests via fetch API.
I see that OPTIONS preflight requests are sent via debugging proxy (Charles Proxy), but they are not displayed in Google Chrome Developer Tools\Network tab.
I don't have any filters setup on the network tab. I remember OPTIONS requests being visible there, but not anymore. How do I bring them back?
You'll need to go to: chrome://flags/#out-of-blink-cors, disable the flag, and restart Chrome.
This is an expected behavior change according to:
https://bugs.chromium.org/p/chromium/issues/detail?id=995740#c1
I originally came across this via:
https://support.google.com/chrome/thread/11089651?hl=en
As of 2021 in CHROME the OPTIONS request is visible in the NETWORK tab filter OTHER requests
To see it together with XHR just CTRL+click and pick the request filters you want to see.
UPDATE (April 17) Chrome Version 90.0.4430.72 has made the options requests hidden again :(
Chrome 81 does not seem to display anything even after changing the option and restarting on my computer.
As an alternative solution, I started to use Firefox and its Network tab for development.
https://getfirefox.com
I'm Takashi from Chromium Project, and drove the Out-Of-Blink/Render CORS project.
The project intended to introduce a process isolated CORS implementation for better security and privacy, and many of new network related features rely on this new implementation. Unfortunately we temporarily disabled preflight support in DevTools as it turned out continuing to support it weakens security and privacy. Sorry for inconvenience during this period.
Good news is now Chrome 83 implements the CORS preflight DevTools support again in a security preserved way. So you can monitor the CORS preflight requests as you could do before the Out-Of-Blink/Renderer CORS.
Best,
I was doing some research on how Firefox and Chrome are implementing HSTS (HTTP Strict Transport Security) in detail.
Turns out that they have a predefined list with some sites that already implement HSTS. This can be seen here here and/or here.
And these list seems to be somehow linked to the sourcecode itself which makes somehow sense...but how do Firefox and Chrome handle my own HSTS headers? How and where do they store my URL, my max-age and whether I includeSubDomains or not?
I wasn't able to find this in about:config or likewise....
So maybe somebody knows more about this issue than me, I'm just curious (:
Thx!
See http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/netwerk/protocol/http/nsHttpChannel.cpp#l1072 and then http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/security/manager/boot/src/nsStrictTransportSecurityService.cpp#l249 which calls http://hg.mozilla.org/mozilla-central/file/20bbf73921f4/security/manager/boot/src/nsStrictTransportSecurityService.cpp#l147
So the data ends up stored in the permission manager, which is the normal place per-host information gets stored in Firefox. The permission manager stores its state in permissions.sqlite, I think.
Sites that want HTTP Strict Transport Security (HSTS) enforced send a header in response - Strict-Transport-Security: max-age=31536000
max age being time for it to expire. It is sent on each request so that it gets updated to that much more time every time it is requested.
Browser (I have tried only Firefox) stores this data with it and will use it every time the site is accessed. This is true even for incognito mode. If you have ever accessed the site before in non incognito mode then the details of that site is saved and used even if you try to open it now in incognito mode.
For firefox this data is stored in a file called SiteSecurityServiceState.txt which is in your firefox profile folder. You can enter about:support in browser and then select "Show in folder" to open your profile folder where you can locate this file.
I am not sure about predefined sites but above is the file where normal site HSTS details are updated for firefox.
More details - Understanding HTTP Strict Transport Security (HSTS)
PS: Above link goes to my personal blog that has more details on HSTS.