Cookie subdomains missing first part of subdomain for non-subdirectory sites

I've rolled this simple patch which appears to fix the problem with the cookie subdomains, although it has a couple other issues:

1. it calls the internal _hosting_subdirs_is_a_subdir_site() function, which by convention should only be called within the hosting_subdirs module (perhaps the logic there should be exposed, or reproduced here?)
2. it appears to break my ability to login to a subdir site when using Nginx.

I'm digging into this further, but thought I'd share the patch in case anyone has comments. I'm suspicious because I noticed that logging into a subdir site using Apache doesn't work for me, regardless- and according to the earlier tickets @colan mentioned, I believe both webservers should allow me to run a password reset and login.

With thanks to @ergonlogic for the lead, I've gone back to the original commit that introduced the bug, creating and writing the aegir.services.yml to specify the cookie domain.

As an experiment, I've commented out the entire aegir.services.tpl.php so no cookie domain is explicitly set by that mechanism. Having cleared caches, I find I can "goto" my test parent site or my test subdirectory site, get logged into each independently (ie. logging into one doesn't log me into the other, and vice versa). Inspecting the cookies on each page, I see I have 2 cookies, each with domain as the full parent uri (eg. .foo.aegir.local), and a path of '/'.

I'm not entirely clear how this is working, off-hand, and I might be missing the problem or the reason the aegir.services.yml was introduced, but I *think* this is the behaviour we want. I'm not certain of the actual failure @colan was describing originally on this ticket, but having reverted to not explicitly setting cookie domain, Drupal seems to handle things elegantly. Perhaps some of the other commits on https://www.drupal.org/project/provision/issues/3025905 took care of the original problem there?

Perhaps some of the other commits on https://www.drupal.org/project/provision/issues/3025905 took care of the original problem there?

I suspect so. We should probably just revert b441a70eb. If we do, it'll leave behind unused aegir.services.yml files. They shouldn't break anything, as they will no longer be included in settings.php. Unfortunately, I don't know of any hook_update_N() mechanism in Drush that'd allow us to delete these cleanly as a one-off.

This also cause cookie issues with any sites in Aegir that don't start with www.

The cookie domain in aegir.services.yml ended up as simply .com

This is a major issue that needs to be fixed ASAP.

Another angle on this ...

When you have a site with alias domains, and set a redirect to something other then the name with which the site was created then you can nolonger login.
The cookie domain set in the services.yml is only based on this->uri (the site node title)

This prevents logins even with a login link.

@ac: The getCookieDomain() function had a line if (count($uri) > 2) { which should prevent 'example.com' turning into '.com' ... but example.co.uk might be a different story. ( we should look at core https://git.drupalcode.org/project/drupal/blob/7.x/includes/bootstrap.in... )

It seems that this cookie domain is needed just for the subdir sites ... could we restrict it to just those sites? ... the settings.php templates are testing for isset($_SERVER['RAW_HOST']

In regards to reverting on #5.

An update hook could try and remove the file but in most cases will fail because of file permissions set on that folder (?), if it fails it should be added as a warning in reports that the file can be removed until such date we need to use it again. An addendum to the documentation on the project page should be sufficient for helping people stumbling upon this issue later on.

We have tested the following on nginx with the latest version (7.x-3.180) using a Drupal 7 site, and here's what we see:

    1. example.org (bare domain)
      1.1. aegir.services.yml: example.org
      1.2. session cookie domains:
          1.2.1 .example.org (path: /)
    2. sub.example.org (subdomain)
      2.1. aegir.services.yml: .example.org
      2.2. session cookie domains:
          2.2.1 .example.org (path: /)
          2.2.2 .sub.example.org (path: /)
    3. example.org/subdir (subdir)
      3.1. aegir.services.yml: .example.org
      3.2. session cookie domains:
          3.2.1 .example.org (path: /)
          3.2.2 .example.org (path: /subdir)
    4. sub.example.org/subdir (subdomain w/ subdir)
      4.1. aegir.services.yml: .sub.example.org
      4.2. session cookie domains:
          4.2.1 .example.org  (path: /)
          4.2.2 .example.org (path: /subdir)
          4.2.3 .sub.example.org  (path: /)
          4.2.4 .sub.example.org (path: /subdir)

@helmo yes you are correct - the domains we had issues with were all .com.au

@llamech did you check any second level domains like .com.au?

Today, we have tested the following on nginx with the latest version (7.x-3.180) using a Drupal 8 site, and here's what we see:

Nginx, drupal 8:
    1. example.net (bare domain) -- login works
      1.1. aegir.services.yml: example.net -- removing this still allows logins
      1.2. session cookie domains:
          1.2.1 example.net (path: /)     -- removing aegir.services.yml results in cookie domain becoming `.example.net` -- more backwards compatible
    2. sub.example.net (subdomain) -- login works
      2.1. aegir.services.yml: .example.net  -- removing this still allows logins, and sets the correct session cookie domain
      2.2. session cookie domains:
          2.2.1 .example.net (path: /)  -- despite logging out of `example.net`, a session cookies is generated for this domain -- removing aegir.services.yml resolves this
          2.2.2 .sub.example.net (path: /)  -- this session cookie is only set if aegir.services.yml is removed 
    3. example.net/subdir (subdir)  -- login works
      3.1. aegir.services.yml: .example.net -- removing this has no effect
      3.2. session cookie domains:
          3.2.1 .example.net (path: /subdir)
    4. sub.example.net/subdir (subdomain w/ subdir)  -- login works
      4.1. aegir.services.yml: .sub.example.net -- removing this has no effect
      4.2. session cookie domains:
          4.2.1 .sub.example.net (path: /subdir)

Now, as per @ac, we've tried the same use cases as above using a 2-part TLD (example.com.au) with Drupal 8 on nginx.

Nginx, drupal 8, 2-part TLD:
    1. example.com.au -- failed to login -- cookie domain was `.com.au`
    1. sub.example.com.au
    1. example.com.au/subdir
    1. sub.example.com.au/subdir

After observing the failure to login in the first example, we only tested the case where we remove aegir.services.yml (since this approach worked on any previous issues that had come up); it fixed whatever issue was blocking login in the first case above, and we saw no further issues with the other cases.

It seems that reverting the commit that introduced aegir.services.yml (mentioned by @ergonlogic above) would be a good first step.

We reverted the problematic commit, so we'll no longer generate `aegir.services.yml`, nor include it in `settings.php`.

As I mentioned in #5, this won't remove existing `aegir.services.yml` files, but they won't be used either. I think a small post-verify hook to clean up these files should be fine. If we ever decide to re-implement the Aegir-generated services file, we can drop the cleanup code.

Cleanup code added in 221354d8.

This should be fixed now in 7.x-3.x, and will make it into the next release.

Noting here that this issue has arisen again: https://www.drupal.org/project/provision/issues/3102849

It would be great if the manual test scripts posted above could be added to the automated tests suites: https://github.com/aegir-project/tests

https://www.drupal.org/project/provision/issues/3066538#comment-13266027