I am trying to load a page as an iframe. It loads correct on Firefox but the request fails on chrome.
JSESSIONID=.......; path=/idp; HttpOnly
Chrome rejects the request by avoiding to set cookie or something similar. I already tried it with an unsecure chrome but still issue exist.
A warning on Firefox:
Cookie “_idp_authn_lc_key” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”.
Also I changed chrome settings to allow cookies from 3rd party. I don't have any extensions on chrome (such as adblock or similar extensions).
The main issue seems to be the default value for samesite on chrome, which is Lax as a default when it is not available, but currently it is none on firefox.
Anybody has an idea how can I change the default on chrome?
Related
I am getting this issue while adding a cookie in Chrome dev tools (it gets highlighted in red), so I am not able to add any cookies. I even tried to reset the Chrome browser, but it's not working.
If you update your chrome or restart your laptop recently(10-Feb-2022), you cannot add cookies manually in chrome now. The reason is the newest update of Chome disable the SameSite by default cookies setting.
the solution is:
open this url in chrome: chrome://flags
search Partitioned cookies, and enable it
The latest version of Chrome (85.0.4183.83) is removing my 3rd party cookies, although they are set as SameSite=None; secure; - how can this be, and am I the only one experiencing this?
They are also HttpOnly, if that matters, and it happens when setting the cookie through a Chrome Extension.
Chrome 85 seems to be removing 3rd party cookies set by Chrome Extensions, regardless of SameSite attribute. It doesn't seem to be documented, so it may be unintended.
I am trying to make a CORS request with credentials(Cookies attached) and Chrome is not attaching the Cookie to my request. I have set the cookie to a sub-domain of the existing page and i could observe it is set successfully from the Cookie manager.
I do not have this problem with Chrome 78th version(latest version). But for the previous versions, I have this problem(I have checked 75 and 77). As well as i do not have any problem with other major browsers also. They also attach cookies without a problem.(I have tested my code with Firefox, IE, Opera and Edge)
This how I have set the Cookie from external service end.
res.setHeader('Set-Cookie','cdn-token=exp3header_same-site-none; domain=.local.com; path=/; SameSite=None;');
Complete sample code base can be found in following links:
External service - https://github.com/bhanukayapa/cors-backend.git
Front-end application - https://github.com/bhanukayapa/cors-angular-frontend.git
Can someone please explain the root cause for this problem? I checked Chrome release notes also. I could not find and bug fix or improvement related to this. Thanks in advance.
If setting SameSite=None this must be paired with Secure. e.g.
res.setHeader('Set-Cookie','cdn-token=exp3header_same-site-none; domain=.local.com; path=/; SameSite=None; Secure');
I am sending a response and setting a maxAge for cookie as -1.All browsers except Chrome delete my cookie once browser is closed.
Chrome browser shows -
But still cookie does not get deleted when I close the browser.How to delete a cookie on chrome?Or is there any robust way which will work on all the browsers?
Likely to be one of these problems:
Chrome is still running in the background even though you closed the browser, so the session did not clear up.
One of the many bugs[1] relating to session cookie deletion problem in chrome.
[1] https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-bugs/session$20cookies$20not$20deleted
As per spec, not setting max-age and expires directives causes browsers to treat your cookie as a session cookie. cookie.setMaxAge(-1) is doing the right thing internally if you say it works on all other browsers except chrome, though you can try setting a cookie without max-age and expires i.e., to have your http header field like this:
Set-Cookie: test=2015; Path=/; Domain=.example.
I believe the robust solution is to go by the spec. Do not bother about setting expires and max-age values, if you'd want a strict session cookie. We, then, leave it upto the browsers to respect the spec.
We use doubleclick from Google to track user information with a floodlight tag in an IFrame, but recently the response is causing an error in the Chrome dev tools:
Invalid 'X-Frame-Options' header encountered when loading 'http://123.fls.doubleclick.net/activityi;src=123;type=123;cat=123;ord=123': 'ALLOWALL' is not a recognized directive. The header will be ignored.
Here is a blog post on the matter: http://ipsec.pl/node/1094
It looks like ALLOWALL has recently been added to allow any site to use the code as a src (similar to not including that option at all) and doubleclick is including this option in their response. Out of IE, Firefox and Chrome, Chrome is the only browser that throws the error. Does that mean that Google is using an option in doubleclick that doesn't work in their own browser? It's hard to imagine a Google team not testing in Chrome.
It seems to me that if the header is being ignored, and the header has the same effect as not including any cross site restrictions with X-Frame-Options, the error will not affect anything. Also, since the error occurs on the response, the tracking that is done with the original request should be fine, right?
The issue was filed as a bug report: Bug 110857 - X-Frame-Options should accept ALLOWALL as a valid value and
has been addressed and the fix is in the main branch of WebKit, once the latest WebKit engine is in use by Chrome, the messages will disappear.
for more information see: Webkit Changeset 144105