Domain Access
public
groups: Access Control · Multisite
agentrickard@dr... - Thu, 2007-10-04 21:12
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 http://skirt.com/map
Sitewide tags: access control · multisite
Ical feed
This is beautiful
I've been playing with this since you told me about it at the Salty Dog. Thanks for contributing this as an official module.
Sure
There will be some changes. In particular, some internal module hooks so it plays nice with others. But it should be ready for use.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Will it work with AnotherDomain.com?
Is this strictly subdomains or could it work just as well with AnotherExampleDomain.com pointed at the same multisite?
~ ben melançon
member, Agaric Design Collective
http://AgaricDesign.com - "Open Source Free Software Web Development"
Almost
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:
Outstanding issues with this approach:
The module structure currently supports this type of feature, which should be written as a submodule against HEAD.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
How does search work then...?
Very interesting module, thank you very much!
Which way to go to implement a switch for "search only on sub.example.com" or "search all content"?
Thanks!
Not sure I understand
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:
I'm not sure how search module interacts with node_access modules, so this anyone who knows more, please chime in.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
multiple options
what i have on mind is the (advanced) searchform should look like this:
serach:_____________
[ ] search this.example.com only
[ ] search *.example.com
the search results should be listed for each subsite, if *.example.com was selected
results for this.example.com:
...
...
results for one.example.com:
...
...
results for two.example.com:
...
...
...
This could be accomplished,
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.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Marrying Domain Access functionality to an OG?
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.
I'm interested in that. What you are describing sounds like the module OG-sites - http://drupal.org/project/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.
a subdomain for each group
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
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.
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:
<?php/**
* Notify other modules that we are granting access to a node.
*
* This hook allows Domain Access modules to overwrite default behaviors.
* See http://api.drupal.org/api/function/hook_node_grants/5 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;
return $grants;
}
?>
And:
<?php/**
* Notify other modules that we are saving node access records.
*
* This hook allows Domain Access modules to overwrite the default bahaviors.
* See http://api.drupal.org/api/function/hook_node_access_records/5 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
);
return $grants;
}
?>
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.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Committed
This hook has been committed to HEAD.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
keep all options for future development
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.
example:
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:
local1.example.com/climate
local2.example.com/gmo
local3.example.com/events
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 localX.example.com/climate 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
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:
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.
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
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:
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):
Wow
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:
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.
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.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Feature: User takes on different default roles across sites
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. :)
Security
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.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Worried for security if not doing this
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
The Domain Access module solves this problem.
You have the following setup:
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.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Perfect!
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! :)
Beta
Thanks.
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: http://therickards.com/api/group/hooks/Domain
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Beta3
I just released beta3, which incorporates some new module hooks.
See http://drupal.org/node/186406
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Next on domaining access to Organic Groups
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:
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. :)))
Right
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.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
beta4
Beta4 has been released, now with Theme support.
http://drupal.org/node/187344
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Beta6
Beta6 is out -- http://drupal.org/node/190940
Includes dynamic table prefixing. Testers wanted!
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Progress
http://drupal.org/node/191375#comment-635244 paves the way for using OG with DA.
Need to commit some more code so folks can test this.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Beta7, with OG support
Beta release 7 is out -- 25-NOV-2007. This release requires that you run update.php. Please see the release notes for detailed changes.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
RC1
Domain Access rc1 is out. http://drupal.org/node/201500
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Error after adding Domain Conf seetings override
Moved to support request at http://drupal.org/node/224079.
Issue queue
This belongs in the formal issue queue.
http://drupal.org/node/add/project-issue/99990
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.
--
http://ken.therickards.com/
http://savannahnow.com/user/2
http://blufftontoday.com/user/3
Patch - installed Domain Access & Organic Groups
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?
thanks
Patching Domain Access & Organic Groups
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/common.inc" and "modules/node/node.module" changed. i compared the result and just do a upload for this two files. but i'm not sure!?
See
http://drupal.org/patch/apply
And perhaps:
http://drupal.org/node/32875
http://drupal.org/node/60179
--
http://ken.therickards.com/
overwhelming
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 skirt.com 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
Support questions go in the issue queue, where they can be tracked and referenced by others.
Please ask again over at http://drupal.org/node/add/project_issue/domain/support
--
http://ken.therickards.com/
And NodeQueue...
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