| Spaced out on Cookies |
|
Has anyone managed to get to the bottom of this ever-present complaint in browsers from quite some time ago:
Cookie “pot” will be soon rejected because it has the “sameSite” attribute set to “none” or an invalid value, without the “secure” attribute. To know more about the “sameSite“ attribute, read https://developer.mozilla.org/docs/Web/H...e/SameSite I've nibbled at every $cookie and $secure setting in CI (including in the system files), and also in php.ini... but there doesn't appear to be an easy, non-hacky way to get the Set-Cookie parameters set appropriately to stop the browsers from complaining (?). The site in question is running under HSTS and has all the CI, Apache and PHP settings set accordingly (even though CI likely over-writes most of the Apache and PHP settings). Also, Config/Cookie.php is set: public $secure = TRUE; public $httponly = TRUE; public $samesite = 'Lax'; [EDIT] also: public $CSPEnabled = TRUE; Even the deprecated equivalents scattered though other config files have been set to similar values (albeit that they are all currently commented to guarantee they're not being used anywhere). Thanks.
This should not be the case, as you have said in your Config\Cookie
public $secure = TRUE; public $samesite = 'Lax'; clearly SameSite here is not 'None' but 'Lax' and the Secure attribute is set. Also, CI4 also checks on runtime if you are setting the samesite to 'none' without the secure attribute being set. It will throw an exception if that's the case. https://github.com/codeigniter4/CodeIgni...#L777-L779 Are you sure the cookie is being set by CI4?
@ paulbalandan
The cookie response is a bit odd... I always get this one: Cookie “pot” will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute This one is almost always present too: Cookie “pot” has been rejected because it is already expired. And this one is only occasional: Cookie “” has been rejected as third-party. Yes, it's an empty "" name cookie?! The first two are definitely from my code, the third one I suspect is not, but I'd have a hard time trying to guess where it's from. A little bit of scratching has subsequently revealed some additional details... which I'll get to in a bit, but a critical bit of background information about this site is that it is pretty much 100% JavaScript driven. There is a pretty basic/nearly blank "background" HTML page that is loaded on any page load or refresh... embedded in this blank page are the scripts that then interact with the server via AJAX/XHR, including pulling down all the necessary content for the UI. When I started this code, one of the first things I did was to make sure the background HTML page was configured and working correctly, with all the required headers (including all the security settings that were needed). Now, although everything still works without impeding functionality, what I find is that NONE of the correct headers (injected via the /system/HTTP/ResponseTrait.php send() command) are being pushed into the background HTML page during a page load/refresh (which is where they all should/need to be sent)... and all of them are being inserted into the AJAX messages (where the JavaScript client-side "workers"- if I could call them that- sort though and discard this additional, and unnecessary, overhead that they're not interested in). Like I say, from the outside, everything works without a functional problem, with only a few niggling complaints like this SameSite cookie issue always being present on the production server (which somehow doesn't ever seem to appear when hosting from the development setup!?!). I'm at a loss as to when/how this functionality somehow became flipped... and what's happened/I've done that stops CI from automatically inserting the headers (done in send())?
Why don't you show the raw HTTP cookie header?
@ kenjis
That's the cause of the browser's warning/complaint... these directives are not being inserted into the headers (by CI) into the server's response. I'm still trying to figure out why they do get inserted into the AJAX messages from the server, but not into a standard HTML page refresh... Not that it's of much use here, but the headers (and the set-cookie directives) that are configured elsewhere (not by CI's ContentSecurityPolicy.php), and are being inserted, are as follows: cache-control: no-store, no-cache, must-revalidate content-language: en content-type: text/html; charset=UTF-8 date: Fri, 18 Feb 2022 17:51:54 GMT expires: Fri, 25 Feb 2022 17:51:54 GMT pragma: no-cache referrer-policy: no-referrer server: Microsoft-IIS set-cookie: pot=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/; HttpOnly << DIRECTIVES MISSING HERE >> << content-security-policy: CSP HEADER, WITH ITS DIRECTIVES MISSING >> strict-transport-security: max-age=31536000; includeSubDomains x-content-type-options: nosniff X-Firefox-Spdy: h2 x-frame-options: deny x-robots-tag: noindex, nofollow x-xss-protection: 1;mode=block
[UPDATE] This appears to be linked to Filter exclusions, whereby when an exclusion is applied, CI totally ignores any of the ContentSecurityPolicy stipulations (and doesn't even bother processing this section of system code). This doesn't seem correct?!?
|
| Welcome Guest, Not a member yet? Register Sign In |
