My site uses the Domain Access module to maintain multiple domains and sub-domains, such as:

  • www.domain1.com, apple.domain1.com, orange.domain1.com
  • www.domain2.com, dog.domain2.com, cat.domain2.com

Users from the same domain (for example, domain1.com) should be able to go back and forth between the different sub-domains (www, apple, orange) without having to log in each time.

If I set the cookie domain inside services.yml, users from domain1 will be able to go back and forth between domain and sub-domain; however, users from domain2 won't be able to use the site.

    cookie_domain: '.domain1.com'

If I don't set cookie_domain, users from either domain will have to log in each time when they go between sub-domains and domain.

In Drupal 7, it was possible to change the cookie configuration dynamically as explained on cookie domain disables other top domains.

In Drupal 8, the cookie_domain is set in a YAML file that can't be changed dynamically. A workaround on Drupal 8 is to load dynamically a different YAML file as explained here: https://bit.ly/2Nwgzlr. However; this is not an option for sites with a large number of domains and sub-domains.

Writing a new YAML file per site and modifying the settings.php every time a new domain is added to the pool, is not the most productive way. There is always a way of overriding things inside the Drupal code. I hope this is not the exception.

Can anyone tell me what hook or class I can use to implement the logic I need?

  • Using Domain Access you must have set your domains somewhere in the config, no? Then get that config, read the domains from there and fire your logic.
    – leymannx
    Mar 2, 2019 at 12:05
  • The README is pretty clear about that: Note that cross-domain login requires the sharing of a top-level domain, so a setting like .example.com will work for all example.com subdomains. @see github.com/agentrickard/domain/blob/8.x-1.x/…
    – leymannx
    Mar 2, 2019 at 12:19
  • If you set the cookie as shown in the sample code included in this question, you can go without re-authenticating across domain and sub-domains of domain1.com; but you can't go between domain and sub-domains of domain2.com. It just doesn't work. Mar 4, 2019 at 16:09
  • Sounds like a wont-fix then for now, no?
    – leymannx
    Mar 4, 2019 at 17:34
  • (I actually do have the same challenge right now. But as long as all domains are hosted on the same server, I think you can work something out. Maybe with something like a real cookie-file, placed in a secure location when accessing the site under one domain, and then reading it on the others and display a login button somewhere, and hitting that reads the information from that cookie-file and triggers programmatic login. But I'm still far from a proof-of-concept. The same problem as you have also occurs when you have multi-language configured to use domains as handler.)
    – leymannx
    Mar 4, 2019 at 17:38

1 Answer 1


You should be able to do this by altering the services container: https://www.drupal.org/docs/8/api/services-and-dependency-injection/altering-existing-services-providing-dynamic-services.

You can put your logic in there to dynamically set/override values that would usually be set static in a .yml file.

  • I think the issue they are facing is a single sign-on issue, which would be handling authentication on an external identity provider of some sort. In such a case each domain will have its own cookie. Reading the linked threads, the cookie is set statically by default, so it needs to be set dynamically so that each domain will have its own cookie. At least that’s what I got. I’m all honesty I’m not completely confident got it right. In which case, you are correct. Well actually you’re correct either way.
    – Jaypan
    Mar 2, 2019 at 12:05
  • 1
    Jaypan, It is a single sign-on requirement across domain and it's sub-domains. Users should be able to go back and forth without being forced to re-authenticate between www.domain1.com, apple.domain1.com, orange.domain1.com; NOT between www.domain1.com and www.domain2.com, which obviously requires an external identity provider. Your suggestion of altering the service container seems the way to go in Drupal 8. Mar 4, 2019 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.