Follow-up to #2522002: Do not strip www. from cookie domain by default because that leaks session cookies to subdomains →
These comments in he comments in default.services.yml are not clear:
# Drupal automatically generates a unique session cookie name based on the
# full domain name used to access the site. This mechanism is sufficient
# for most use-cases, including multi-site deployments. However, if it is
# desired that a session can be reused across different subdomains, the
# cookie domain needs to be set to the shared base domain. Doing so assures
# that users remain logged in as they cross between various subdomains.
# To maximize compatibility and normalize the behavior across user agents,
# the cookie domain should start with a dot.
#
Update the documentation to clarify something like 'Sessions themselves will only be synchronized across subdomains if they are all served from the same Drupal installation or if some other session sharing mechanism is implemented'.
patch
review
None
nnone
none
Fixed
11.0 🔥
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
It would make a good project for someone who is new to the Drupal contribution process. It's preferred over Newbie.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Automatically closed - issue fixed for 2 weeks with no activity.