Domain Access

agentrickard's picture

For a project, we just came up with another way to skin the multisite problem.

Domain Access is a node access module that enables multiple sites to be run from one installation.

The beta has been released.

See the module in action at


This is beautiful

christefano's picture

I've been playing with this since you told me about it at the Salty Dog. Thanks for contributing this as an official module.


agentrickard's picture

There will be some changes. In particular, some internal module hooks so it plays nice with others. But it should be ready for use.


Will it work with

mlncn's picture

Is this strictly subdomains or could it work just as well with pointed at the same multisite?

~ ben melançon

member, Agaric Design Collective - "Open Source Free Software Web Development"

benjamin, agaric


agentrickard's picture

Right now it is strictly subdomains, which was the original design requirement.

The limitation is setting multiple login cookies across the domains (which is a browser security standard, not a Drupal or a module problem). The Single-sign on module doesn't quite work under Domain Access -- SSO is looking for individual folders for each domain, and those don't exist.

The module infrastructure would allow multiple domains, but you'd have to solve the login problem.

One ugly solution that we've discussed is this:

  • Use hook_form_alter() to add a #submit function to all login forms.
  • On login, check each active domain record.
  • Store the user-specific data in some temporary way (cache table, maybe?)
  • For each unique top-level domain, run drupal_goto() and hit a specific login handler.
  • Grab the temporary data and use it to write a cookie for each domain.
  • Return to the original request page.

Outstanding issues with this approach:

  • How to determine the uniqueness of the temporary value without introducing a race condition. (Using the value from form_token, maybe?)
  • How to handle logouts without hacking core -- since logout is not a form.
  • Would the goto process simply take too long to be feasible?

The module structure currently supports this type of feature, which should be written as a submodule against HEAD.


gauravvdeshpande's picture

I am working for
Initially I was thinking of using domain access module, but as of it was mean for sub-domains only, I am using shared table method. Now I came across automatic login to multiple domain problem. I had tried with SSO thats causing issue of redirection to master domain ,I am working for the multiple domain with same problem., can I have any reference link for your solution to automatic login to multiple domain with reference to solution you have suggested above.

Thanks & Regards,


Gaurav Deshpande

Everything Opensource way

gauravvdeshpande's picture

I am working for multiple domain drupal websites.
Initially I was thinking of using domain access module, but as of it was mean for sub-domains only, I am using shared database table method. Now I came across automatic login to multiple domain problem. I had tried with SSO thats causing issue of redirection to master domain ,I am working for the multiple domain with same problem., can I have any reference link for your solution to automatic login to multiple domain with reference to solution you have suggested above.

Thanks & Regards,


Gaurav Deshpande

Everything Opensource way

resurrecting an old thread

ncameron's picture

resurrecting an old thread again, but I have exactly this problem, did you ever come up with a solution for it?



Open Source Web Solutions

How does search work then...?

drupalista's picture

Very interesting module, thank you very much!

Which way to go to implement a switch for "search only on" or "search all content"?


Not sure I understand

agentrickard's picture

I'm not sure I understand the question. Let me see if I get it:

On node search, nodes from all sites are returned? Regardless of the current domain?

Can you define what you'd like to have happen when:

  • Someone searches from (the default site)
  • Same search from
  • Same search from

I'm not sure how search module interacts with node_access modules, so this anyone who knows more, please chime in.


multiple options

drupalista's picture

what i have on mind is the (advanced) searchform should look like this:


[ ] search only
[ ] search *

the search results should be listed for each subsite, if * was selected

results for

results for

results for


This could be accomplished,

agentrickard's picture

This could be accomplished, I believe, with a Domain Search module that implements hook_search().

The thing to test is how the search behaves across the different subdomains.


Marrying Domain Access functionality to an OG?

john.freebury's picture

Thanks for this contribution. Promising indeed!

I am working on a site which is primarily based around the needs of teams within a diverse organization. The site has a domain with subdomains, but more than anything, it has groups, many groups, and a number of these which have their own public websites with a single sign-on. Domain Access works great for dealing with the domains, but I'm wondering how it might overlay with organic groups. Is there a way to marry the functionality of Domain Access to an OG? And if not, who is interested?

I'm interested in that.

Michael Hofmockel's picture

I'm interested in that. What you are describing sounds like the module OG-sites - . I tried OG sites and was disappointed.

But Domain Access with OG sounds like an interesting combinations that fits my current needs. This could solve some other issues of search that have been discussed.

Michael Hofmockel

Open Source || Open Access || Open Mind

a subdomain for each group

drupalista's picture

This is exactly what I need: each Organic Group should have its subdomain. Is this not possible right now? i am still fiddling with the multisite security aspects, so this question is still on my TODO...

So how do groups and subdomains play together? Do they???

And what exactly was disappointing with the og_sites module?

Ant, btw, what about search then (see other question...)

Thanks for your attention!

Not tested

agentrickard's picture

I originally wrote Domain Access so we wouldn't have to use OG and OG sites, so the module has not been tested in concert with OG.

However, I have some code (not yet committed) that I think will allow this to work as an extension module.

Let me try to explain.

  • Both Domain Access and OG work by writing node_access rules.
  • Node_access rules are written by hook_node_access_records()
  • Node_access rules are applies by hook_node_grants()

  • The problem is that both OG and Domain Access set their own grants, and the node_access system is permissive. That is, if either module grants you access, you get access.

My proposed solution for this is to introduce two Domain Access hooks:

* Notify other modules that we are granting access to a node.
* This hook allows Domain Access modules to overwrite default behaviors.
* See for more detail.
* @param &$grants
*  The existing default $grants, passed by reference.
* @param $account
*  The user object of the user requesting the node.
* @param $op
*  The node operation being performed (view, update, or delete).
* @return
*  No return value. Modify the $grants array, passed by reference.
* @ingroup hooks
function hook_domaingrants(&$grants, $account, $op) {
// Add a sample grant privilege to let a user see their content at all times.
$grants['domain_example'][] = $account->uid;


* Notify other modules that we are saving node access records.
* This hook allows Domain Access modules to overwrite the default bahaviors.
* See for more detail.
* @param &$grants
*  The existing default $grants, passed by reference.
* @param $node
*  The node object being saved.
* @return
*  No return value. Modify the $grants array, passed by reference.
* @ingroup domain
function hook_domainrecords(&$grants, $node) {
// Add a sample access record to let a user see their content at all times.
$grants[] = array(
'realm' => 'domain_example',
'gid' => $node->uid,
'grant_view' => TRUE,
'grant_update' => TRUE,
'grant_delete' => TRUE,
'priority' => 0,         // If this value is > 0, then other grants will not be recorded

These hooks would allow for the creation of a Domain OG module, which would modify the node_access rules for the core Domain Access module to work smoothly with OG. Remember that during the hook implementation, you could add or remove grants as needed. So you might check to see if the node belonged to a group, and if the group belonged to the domain.

At least in theory. But I think that would only work if the groups themselves were restricted to specific domains.

What we really need are some use-cases. How should Domain Access and OG intersect? Some examples:

  • Do groups span across all Domains? -- This is perhaps the easiest solution, and should be supported right now. In this case, all group nodes would be assigned to 'all affiliate sites', then the group and its nodes (I believe) would be viewable across all the active domains.

  • Are groups Domain specific? -- This one is trickier.

  • Can a user in Group X, which belongs to Domain Y see Group X nodes on Domain Z?

  • Or can a user in Group X, which belong to Domain Y, only see Group X nodes on Domain Y? -- This is where the above hooks might be useful.



keep all options for future development

drupalista's picture

The group-domain-access possibilities are really, really VERY interesting and could open doors to some really useful "enterprise" features, where we are always confronted with exactly this kind of model: users work in different domains, each domain has working groups for the same issues and the working groups need to collaborate across domains.


local groups of a global organization want to have their own local site with local events, discussions, users... they think globally and act locally, so the local groups work on the same issues:

With domain-groups local groups could not only exchange content easily, it would be a great win for them to understand the structure and work of other local groups immediately, because they work with the same system and so they can find relevant things very easily! They will just have to go to and know everything, because they are very familiar with the system. GREAT!

so my answers to your questions: yes, yes, yes and yes. ;)

I vote for keeping all options open for future development!

I have some other point on my TODO related to this: how does OG work with openid? Maybe this is another approach to realize the described model above.

Thanks for your attention!

group domain access use cases

john.freebury's picture

Please help me refine these use cases/description.

This is not 'enterprise' in the commercial sense but would be really useful to larger international not-for-profit groups! It's essential really.

Here is a list of use cases and description which attempts to summarize what a group-domain-access might look like. I encourage your feedback. From my ultimate wish-list I have included the idea that 'sharing' ideally be separated from 'using' -- you may disagree.

  • Hereinafter, 'domain' and 'subdomain' will be referred to as 'site' and 'affiliate site' respectively.

  • The user shall login from any site or affiliate site and will not, by default, be redirected to a hub site, although that possibility would exist.

  • The system handles both unique sites and affiliate sites.

  • The design must be able to handle over 25 sites and/or affiliate sites (a note for optimization).

  • The unauthenticated user will only see public sites/affiliate sites.

  • The authenticated user will see a list of all public groups and groups to which they are a member, navigating to the group's team homepage. This list of groups will be from any site/affiliate site (the existence of sites remains hidden -- groups dominate).

  • A superuser role will see all groups regardless.

  • A site may have many groups associated with it -- when a user creates a new site at least one group must be specified -- that group's content (team homepage etc.) will automatically be linked to the new site.

  • Groups become the basis for determining all publishing options (sites/affiliate sites are hidden) -- one site url to many groups might ensure a consistent publishing model.

  • When navigating within any site the user will be presented with site specific menus, theme, blocks, and nodes.

  • In the same spirit, the administrators of a specific site/affiliate site are only presented with the menus, themes, and blocks relevant to that site (so they are not sorting through hundreds of menu blocks of other sites, for example).

  • Roles will be consistent across all sites and affliliated site -- these roles will determine the access permissions of site visitors who are not group members.

  • Group permissions (group roles) will determine the access permissions of members within a group.

  • Users and groups will experience a clear separation between the idea of 'sharing' content and 'using' content:

    • Sharing is when the group creating the content determines which groups are allowing to use their content.
    • Using content will be the act of selecting the content of other groups which have been shared (to be incorporated into one's own).
    • By default, only members of a group to which the content belongs will have permission to edit and/or delete.
  • When a user creates a story while in group1 (having site1) that content is published by default in the content of group1 (site1) and may be shared to other groups as specified.

    • If the group does not have a site/affiliate site, then it works the same.
  • When a user creates a story while in group2 (having affiliate site2 (of site1)), that content is not automatically published to site1 -- rather it is optional to share it to that site's group (group1).

  • When group1 shares storyX with group2, the story appears to members of group2 in a list of content that has been shared to group2 from other groups -- with the right permissions a user could then select storyX and use it as though it were its own, adding it to a news block for example.



Thoughts? Comments?

More use cases's picture

A big thank you for this module which is getting better and better. It is the closest thing I have seen so far to the multiple site functionality I am needing for an international NGO with an international web presence, as well as national and local affiliates, each of which needs its own public and linked private (community) site. My points below may be similar to the last post (we are working on the same issues) but may be expressed differently.

There are still a couple of big issues for us:

  1. For each domain/subdomain, the ability to control content so that it can be published either on the ‘public’ site, and/or on the ‘private’ (community) site.
  2. The ability to distinguish between content ‘use’ and content ‘sharing’ – i.e. within each domain, a node may be ‘used’ (published) on either the public site and/or the private site, AND it may be ‘shared’ with the network but not actually published on other public or private sites until/if the webmaster of each decides to do so.

You asked for use cases. Here are a few which we have to meet (some of which may already be wholly or partly met by Domain Access):

  • Each website (an international one, and 20-50 national and programme-oriented ones) needs to have both
    • A ‘public’ part (for anonymous users) and
    • A ‘private’, community part (for authenticated users)
  • Users are shared across all sites, so that any authenticated user has access to the ‘private’ part of any website, and is able to move seamlessly between these ‘private’ websites without being required to log in again.
  • Each private website must have one or many ‘groups’, specific to that website. Groups do not need to span domains/websites.
  • Access to some content on each private website must be able to be limited to a group. Groups need to be able to have their own Group pages/menus, etc within any domain/site.
  • Thus a node published on Site X would generate the following possible options:
    • It could be published by Webmaster X only on Private Site X and/or on Public Site X
    • It could be shared with the Network (all sites) but not actually published anywhere else by default
    • Webmaster Y could then decide to publish this node only on Private Site Y and/or on Public Site Y
    • Only the creator of the node (Webmaster X in this example) is allowed to edit/delete the node
    • Webmaster X needs to be able to publish the node only to Group Z (a group exclusive to Site X), in which case it would be visible only to members of Group Z on Private Site X and not anywhere else on Site X or in the Network.
  • Webmasters of Sites Y and Z obviously need a method to view all nodes which have been ‘shared’ by other Sites, and decide whether to publish them to their site.
  • The only amendment to the general rules above might be that a node published in Site X (but not restricted to a Group) might automatically also be published to Private Site A (the private/community section of the parent/hub/international site).


agentrickard's picture

OK, color me impressed. It will take me a while to absorb all the use cases in this thread. Here's what I can pledge:

I'll try to architect the core Domain Access module so that it can be extended to cover your use-cases. That doesn't, however, mean that I'll write the modules that implement those use-cases. So this thread will be very helpful to developers looking to extend th module.

Note: I actually have a developer in the room next to me working on extending the module with selective table-prefixing (work which will become the Domain Prefix module). I should also say that I want to keep the core Domain Access module very small, and these kinds of complex use-cases separate from the base functionality.

I can, however, address there two points right now:

There are still a couple of big issues for us:

1. For each domain/subdomain, the ability to control content so that it can be published either on the ‘public’ site, and/or on the ‘private’ (community) site.
2. The ability to distinguish between content ‘use’ and content ‘sharing’ – i.e. within each domain, a node may be ‘used’ (published) on either the public site and/or the private site, AND it may be ‘shared’ with the network but not actually published on other public or private sites until/if the webmaster of each decides to do so.

  1. Well, this is supported now for users with the 'set domain access' privielege, but there are no default settings, which is what I think you're asking for. This shouldn't be too hard to implement. Right now, we do something similar based on node types -- each node type can be autopublished to 'all affiliates'. Extending the module in this direction makes sense. This would be a domain-specific setting and requires some changes to the core Domain Access module.

  2. This is a tricky issue, since typically it requires the 'administer nodes' permission to view unpublished nodes. The Domain Content module starts to solve this problem. Really it sounds like you want each affliliate site toi have separate pulished/unpublished status for each node.

I think an extension module could handle this. You'd need a {domain_node} table that stored NID, DOMAIN_ID, STATUS, and possibly other data. Then you would use hook_form_alter() to add this setting to the node form -- you might also create a settings option for default options for each affiliate.

Then during node_load(), you would overwrite the status of the node with the data taken from {domain_node} for that NID on that DOMAIN_ID.

In theory, that should work.


dnosker's picture

Not sure how hard this would be but how about adding the following feature:

User takes on different role depending on site. Example:

... User logs in on main hub site. Is given his default role as normal.

... User goes to affiliate site and then automatically takes on different role for that site. So I guess this would involve some kind of user/roles settings per site feature?

Would this be too hard to make happen? I can see a huge advantage to this!

But just my 2 cents worth for a suggestion. :)


agentrickard's picture

Something like this came up on the development list a few weeks back, and most people agreed that it was a very bad idea from a security perspective.


Worried for security if not doing this

dnosker's picture

I guess what bothers me a little is the actual security problems with NOT implimenting something like this.

Example: I assign a manager of all content at site B, and another individual at site C. The MGR at site B with his default role is able to change everything also on site C.

This is actually a big problem now with sharing users in a multi-site configuration. The only way to handle that now is to NOT share users accross sites and keep the sites totally seperate.

Wish that this problem would finally get solved through some kind of module! :)

Just some further discussion for thought.

Domain Access & Domain Content

agentrickard's picture

The Domain Access module solves this problem.

You have the following setup:

  • Main Site
  • Affiliate Site A
  • Affiliate Site B

Only give superusers the 'administer nodes' permission and the 'edit TYPE nodes' permissions.

Editors for sites A and B are given the 'edit domain nodes' permission, and their user accounts are configured to assign them as editors of sites A and B, respectively.

Only users with the 'set domain access' permission can assign users and nodes to domains. For all other users, these ar set automatically.

See the README.txt for documentation of these features.

Also see the included Domain Content module, which separates the Administer Content screen into affiliate sites.



dnosker's picture

This is perfect! This really is a great module that solves so many problems!

The last thing I would like to see is to ensure that the module works well with Organic Groups. I think I read somewhere that you mentioned you had some untested code towards this end. For me, I really need this as I would like to use groups in most of my sites and would love to share content across sites for these groups.

BTW... Big congrats on this module. It's about time someone finally put something together that makes sense! :)


agentrickard's picture


Be warned that the module is in beta -- we're doing our second deployment of it this week and found two important bugs today.

The supporting code for OG has been committed -- but it doesn't actually do anything. What I built are some internal module hooks that will let an additional module adjust the node_access rules that are set by the Domain Access module.

Using those hooks should let people write OG-compatible modules that write the node_access rules in ways that support the use cases outlined above.

The problem, however, is that I doubt I can support all use cases myself. It will fall to other to write the extension modules to support the type of complex group/domain access rules described above.

I have some more code to commit, and a new beta to release. After which, the API will be updated at:



Next on domaining access to Organic Groups

john.freebury's picture

I am wondering what should happen next. Here are some thoughts...

What all of those use cases above may amount to, to my mind, is a way to allow for domain_access functionality to disappear behind organic groups. And when a user moves from one group to another they may not see much, but when they go from a group in one domain to a group in another, they may notice that the url has changed and perhaps the theming and menus also. The human administrators of groups also needs to be operating in a world of relative simplicity.

So here are a few module suggestions which come to mind that will extend Domain Access to integrate with Organic Groups:

  • a module which sets groups within a domain (allowing multiple groups in one domain).
  • a module for over-riding the current domain_access publishing model so that publishing is based on groups instead of domains (domains become hidden in the publishing system).
  • a module for domain/subdomain specific theming, menus, views, and blocks (perhaps 4 modules or more), so that if a group has it's own domain/subdomain, it has relative independence, if not, then is interdependent with other groups of that domain/subdomain.
  • a module which organizes groups into hierarchies to match their domain/subdomain configuration.
  • a hand-shake module between groups for 'sharing' and 'using' content (see use cases above, and may be just an OG module). There would be two behaviours in this module -- one for sharing/using across all groups of domain/subdomains by default, and another for sharing/using only between the groups of a specific domain/subdomain. Perhaps a thrid behaviour would be to limit this kind of sharing between all groups in a domain and it's subdomains.
  • a module which sets defaults for the automatic publishing of content between groups (think hub and spokes, and may be just an OG module). This module might also have different behaviours for how automatic publishing was across all sites, or was limited to domain/subdomain structures.

Or something along these lines. This is all just brainstorming from my point of view.

If there are people ready to build these type of modules for Domain Access, then perhaps we need to leave this thread and begin discussing a few projects. :)))


agentrickard's picture

I think you should open specific issue threads. Perhaps one for each use-case.

Note that this request is supported: "to allow for domain_access functionality to disappear behind organic groups"

beta3 includes two internal hooks:

hook_domainrecords(&$grants, $node)

Lets you override the default Domain Access node access records when saving a node.

hook_domaingrants(&$grants, $account, $op)

Lets you override the default Domain Access node grants when loading or viewing a node. The override works because the $grants are passed by reference. (I wonder why core node_access doesn't do this, btw).

I would suspect that restricting the node type 'og' to a domain, and then letting og handle the grants for other node types might be a good first step.

Tracking these experiments in issues will be important, because node access gets complicated quickly.





agentrickard's picture paves the way for using OG with DA.

Need to commit some more code so folks can test this.


Beta7, with OG support

agentrickard's picture

Beta release 7 is out -- 25-NOV-2007. This release requires that you run update.php. Please see the release notes for detailed changes.



Error after adding Domain Conf seetings override

SeedTreeLLC's picture

Moved to support request at

Issue queue

agentrickard's picture

This belongs in the formal issue queue.

And I just tried to break this on my test server and could not.

Have you configured the main module before installing the Domain Conf include?

Please answer in the issue queue -- the queue gets tracked for support requests.


Patch - installed Domain Access & Organic Groups

telefunken's picture

i have no comandline, so how can i patch it? is it possible to start the patch in browser? is anywhere a zip package download for the patched files, to upload it manualy via ftp? is it possible to patch with a drupalmodule, that can do this?


Patching Domain Access & Organic Groups

telefunken's picture

sorry, i'm not sure if this is the right place to write about the patch problem. i've done the patch under windows with "cygwin". a lot of work for changing 2 files....could it be, that just "includes/" and "modules/node/node.module" changed. i compared the result and just do a upload for this two files. but i'm not sure!?


telefunken's picture

got it and it's overwhelming. thank you for this great piece of work.
one more question. i'm wondering if i should use 'pathauto' or 'global redirect'. i just want to change 'node' in german 'artikel'.
i went to and see that you dont use pathauto or anything. Also the setting 'Node link patterns' is not so clear to me.
and i tried to search here. but nothing. will i expect problems using 'pathauto' or 'global redirect'?

Great stuff! Thank you!

Issue queue

agentrickard's picture

Support questions go in the issue queue, where they can be tracked and referenced by others.

Please ask again over at


And NodeQueue...

prosk's picture

Wonderful Work!!
I have understood your section prefixed Table, wich is very useful in a multidomain management.

I have the Nodequeue module, Do you know if it is possible to show only nodes for the current domain? I will modify the search query in the nodequeue module.

Another problem... The anonymous user cannot view content for a current domain... Is it Normal?

Thanks a lot

looking for cases , could any one share?

haojiang's picture

now i only success with the case about domain menus configuration metioned here "",which is metioned in "".

well , are there any documents like the one above , which share their experiences or samples? thx

and , how to set a user as an administrator of a subdomain ?
i tried to using "table prefix " to "create" all user tables , so that in the subdomain i can create one as the first user who of course is the administrator , but then the subdomain can't view the content of the main-domain.

by the way , is it possible to let a subdomain user (not administrator of the main domain) to use panels or views to theme the subdomain?

thx a lot

Troubles to set up multisite using Domain Access

manuel_mra's picture

I'm trying to setup Domain Access and it doesn't work. The first problem to install is that i don't find a guide how to setup Virtual Host in a hosting site. I have read some comments that i need to go in the httpd.conf of Apache but in a hosting environment i have no access. If this first thing doesn't work it won't be able to work the rest.
Can you help me ?.



greggmarshall's picture

There is a very comprehensive readme.txt that I think is often overlooked in many modules (I know I forget to look), and is especially crucial with Domain Access.


manuel_mra's picture

Hi :
In the install.txt there is a point : 2.2 Server Configuration that doesn't guide how to install in hosting environment. In this page : there is people asking how to install in that environment with no results. In the readme.txt there is a reference : with no much help. And i'm still looking for a page it can guide me with success. Almost all the websites are in a hosting environment.
It seems that i'm not the only one who wants a success with this module because i think it's a cool module.
I hope anyone can help not only to me but to all who are looking for a simple guide.


It is quite confusing, but it

greggmarshall's picture

It is quite confusing, but it is also totally server configuration dependent, so it would be hard to have a single set of instructions work across all server configurations. I did it twice, once on a virtual private server, and once on shared hosting. Both had to be configured in different ways (obviously the shared hosting has a different level of access through cPanel than a VPS with shell access).

I only wish I had kept track of what all I had to do, but it seemed to me other than one blind alley or so that following the readme.txt instructions got me there.

Checking my notebook it would appear I have a print out of some blog post about setting up Domain Access but no URL. Maybe Googling Drupal Domain Access will come up with additional information...

If you are using a shared

jeremyr's picture

If you are using a shared host and only have cPanel access, it's very simple. Just create a sub domain (in cPanel) and instead of giving it a name just put in * then make sure it points to your drupal install.

For example, if Drupal is installed in the document root, you would create the * subdomain record and point it to /home/yourusername/public_html

Then continue the instructions in the readme.txt file.

Handbook pages

nonsie's picture

You might want to take a look at Domain handbook page on installation - Each hosting company is different. It might help if you clarify which hosting company you are using/which tools they have available

Domain reference module

mathieso's picture

Created a domain reference module, in the sandbox at Doesn't do all that a true entity reference would do, but useful in some situations.

Feedback welcome.


Kieran Mathieson