Here's my setup - I have a user that has 'edit domain nodes' permission yet when this user tries to navigate to admin/domain/content/domain_id (where domain_id is the domain he is assigned to) he will get access denied. admin/domain/content correctly only lists the domains the user is assigned to. The user is on the same domain he is attempting to view content for.
I've managed to track it down to the domain list size variable - if my domain list size is set to greater than the # of existing domains admin/domain/content/domain_id will produce the content assigned to the domain as expected. If the list size is set to less it will result in access denied.
So looking at the actual implementation of hook_menu if domain list size <= # of domains it uses
'access callback' => 'domain_content_check',
'access arguments' => array($domain),
and if domain list size > #domains
'access callback' => 'domain_content_check',
'access arguments' => array(3),
The difference here is that one passes the whole domain array while second just passes domain ID to domain_content_check.
domain_content_check() expects it to be an array at all times.
Shall we:
1. always pass domain_id and load domain details in domain_content_check()
2. always pass domain_id and rely on domain_id to do the comparison
I don't see any purpose for #1 as it stands ATM.
(And I almost thought I had killed one of my sites after an upgrade yesterday. Whew!)
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 698566-domain-content.patch | 10.41 KB | agentrickard |
| #3 | 698566-domain-content.patch | 5 KB | agentrickard |
| #1 | contributions-modules-domain-698566.patch | 2.85 KB | nonsie |
Comments
Comment #1
nonsieHere's a possible patch using #2
Comment #2
agentrickardThat'll take a little thought. Sounds right, though.
Comment #3
agentrickardThis needs a lot of thought. There is some weird handling of the 'edit' link on Domain Content pages, and the 'review content for all domains' permission doesn't work as expected, so we need to review domain_content_list() and domain_content_form() and how they interact with domain_content_check().
There are no actual security issues here, since the edit link fails for non-privileged users, but we should not show it in those cases.
Patch reformatted to domain root directory.
Comment #4
agentrickardOK, here's a patch, from DA root that cleans up a whole bunch of old cruft.
It requires rebuilding menus.
This is the only release blocker to 6.x.2.2...
Comment #5
agentrickardTagging.
Comment #6
nonsieWorks as expected. How would we force menu rebuild though? Domain Content atm has no install file and this update function doesn't really belong in domain.install
Comment #7
agentrickardA note in the release that says "go refresh your modules page". Admins are always warned to run update.php when new or updated modules are installed, which rebuilds the menu.
So we have to trust admins to RTFM.
Comment #8
agentrickardCommitted to HEAD and 6--2!