Problem/Motivation

There seems to be a problem with the way the aucp13n cookie is generated. It is marked as secure and thus would require a samesite attribute of "None" in recent Browsers (chrome > 80, possibly others).

Steps to reproduce

Check cookie value and date in chrome, the cookie will get regenerated for each request. You can also inspect the sent headers, the cookie will not get sent to the server.

Proposed resolution

Send samesite attribute, I guess.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

killes@www.drop.org created an issue. See original summary.

znerol’s picture

znerol commented

Thanks for the report, good points. I'll take a look on how D7 core was changed to support modern browsers.

znerol’s picture

znerol commented

Guess that this one is relevant: #3170525: Set samesite cookie attribute for PHP sessions

znerol’s picture

znerol commented

I'm having difficulties to reproduce the issue. Do you know of a public site which is affected by this problem?

killes@www.drop.org’s picture

killes@www.drop.org commented

sent you a mail through the contact form.

znerol’s picture

znerol commented

Thanks. I believe that there might be conflict with EU Cookie Compliance (GDPR Compliance). That one has an allow-list of cookies the user accepted. Everything else is cleaned out regularly. This can be observed by adding a breakpoint inside the Drupal.eu_cookie_compliance.BlockCookies function. Note that also the core has_js cookie is deleted. I really hope that nobody is still using that one though.

I'm leaving this issue open because I am honestly not quite sure whether the SameSite attribute needs to be set and if yes what value to use. I was under the impression that this is only affecting cross-origin requests and thus I'd set it to Strict for good measure. But since the cache busting cookie is just a random value we might just leave it at the default value and let browsers decide.

killes@www.drop.org’s picture

killes@www.drop.org commented

I also was assuming that this change would not affect this module because we don't actually do a cross-site request.

However, chrome (In my case chromium 83.0.4103.116 ) seemed to disagree.

I was able to see the cookie being stored, but I was also able to see, in the developer tools, that it was not sent along on the following request.

Now, I can't reproduce it anymore myself. Very weird.

I'll keep this updated and will also look into the cookie compliance script.

znerol’s picture

znerol commented

I was able to see the cookie being stored, but I was also able to see, in the developer tools, that it was not sent along on the following request.

Yes, that's exactly what I see as well. The fun thing is that Chromium developer tools in Applications / Cookies / your-domain.com initially shows all cookies. Now refresh the list after some time (with the recycling button just above the Name column). After that the cookies are gone (except for the session cookie). That's the effect of compliance script going after its business, i.e. removing unknown cookies :)

killes@www.drop.org’s picture

killes@www.drop.org commented
Status: Active » Closed (cannot reproduce)

I was using the network tab, and I don't think Chrome makes any changes there after the fact.

Anyway, I suggest we close this. Whatever it was is fixed for now.