Problem/Motivation
It looks like Symfony sets SameSite=Lax by default on cookies. For Drupal core, it's possible to set cookie_samesite: 'Strict' in your services.yml and session cookies are set with SameSite=Strict as expected. This module doesn't seem to set this value at all and so Persistent Login cookies get set with SameSite=Lax
More info on the attribute:
- https://scotthelme.co.uk/tough-cookies/#samesitecookies
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#att...
Steps to reproduce
Set cookie_samesite: 'Strict' in your services.yml; log in with the "Remember me" checkbox checked; look at cookies; session cookie should SameSite=Strict but Persistent Login cookie will be SameSite=Lax
Proposed resolution
Allow setting the SameSite attribute somehow, either directly in this module's configuration, or fetched from the container parameters if the value exists.
Remaining tasks
See above.
User interface changes
Either none or an additional field on the configuration form.
API changes
None?
Data model changes
Does additional config count?
Comments
Comment #2
ambient.impactFixed typo.
Comment #3
gapplePL uses config from core's session management as much as possible, so I think it should just use
cookie_samesite. I don't expect there's a reason for a site to want different settings for session and PL cookies.Comment #4
ambient.impactThat makes sense, yeah. In this case it's more that it doesn't seem to even be doing that, in that the cookie is set with
Laxeven though my container parameters are:As far as I can tell, it looks like
\Symfony\Component\HttpFoundation\Cookie::create()has the parameter$sameSite = self::SAMESITE_LAX, and you explicitly create an instance in\Drupal\persistent_login\EventSubscriber\TokenHandler::setTokenOnResponseEvent()like so:...which I'm assuming defaults to
$sameSite = self::SAMESITE_LAXbecause you didn't provide the$sameSiteparameter and it's using the default value hard coded into that Symfony class rather than automagically using the container parameters.The quick fix would be to just get the
cookie_samesitecontainer parameter and pass it explicitly to\Symfony\Component\HttpFoundation\Cookie::create().I could throw together a test to demonstrate this if you'd like. Either it turns out I'm doing something dumb (entirely possible), or this is a legit issue with this module that's flown under the radar because most people haven't tried to harden cookies with these attributes.
Comment #5
ambient.impactHad this rattling around in my brain the other day and realized a better way to summarize what's probably going on here: the container session parameters very likely only apply to the cookie that identifies the session to Symfony/Drupal, not any other cookies; cookies that are set to expire with the session aren't the same thing, and Symfony doesn't know you want the same behaviour as the session identifier cookie because as far as it knows, you're setting a cookie that has little to do with the session itself.
Comment #7
gappleThis allowed me to figure out setting the cookie path consistently with the session cookie too 😀.
I don't expect anyone would want to change the httponly attribute, but that will now follow the service parameter as well if it's changed.
Comment #8
ambient.impactHeck yeah. Glad to be of help!