Hi. Thanks for all the work on this great module.

Running into a loose end and might be a bug. Not sure. The aim is to have a user, with the 'View unpublished content on assigned domains' permission, able to view an unpublished node from a single domain.

Access doesn't seem to be the problem - just the path the user can hit.

The user can access unpublished content which they are already authorised to access from a single domain... from ANY registered domain, not just the one/s the unpublished content is assigned to publish to.

Steps:
- I enabled Domain Access 7-x-3.3 and registered TWO domains, domain #A and #B.
- I created a node published only to domain #A and a user assigned only to domain #A as well.
- When the node is published, everything seems fine. Attempting to access the node from domain #A it appears, and attempting to access it from domain #B, access is denied. When the node is unpublished however and the user has permission to 'View unpublished content on assigned domains', the user can access the node from EITHER domain #A or #B.

The user isn't gaining any unauthorised access to unpublished content, just that once they have it, they can utilise it via ANY registered domain.

When content is published it is only accessible from the domain/s that content is assigned to publish to. I'm assuming (perhaps naively) that unpublished content should behave the same way. Do you have any tips on this if it's not a bug? Thanks

Comments

Title:Unpublished content is unrestricted for approved usersUnpublished content URL is unrestricted for approved users

I think substituting 'domain URL' for all instances of 'domain' in the description might be more accurate. It's not a content access issue. I've roughly gathered it's a path or URL rewrite issue.

Status:Active» Needs review
StatusFileSize
new635 bytes

I see. The problem is here, in domain_node_access_view():

<?php
 
// The actual access check.
 
foreach ($node->domains as $key => $value) {
    if (!empty(
$account->domain_user[$key])) {
      return
NODE_ACCESS_ALLOW;
    }
  }
?>

Here's a patch that restricts the access to only the current domain. In most cases, however, the EDIT link should be on the proper domain, but this may be more proper.

StatusFileSize
new659 bytes

I added in a check in case the node is published to 'Send to all affiliates' as well.

<?php
 
// The actual access check.
 
$domain = domain_get_domain();
 
$domain_id = $domain['domain_id'];
  if ((isset(
$node->domains[$domain_id]) || $node->domain_site) && !empty($account->domain_user[$domain_id])) {
    return
NODE_ACCESS_ALLOW;
  }
?>
Also, what do you mean by this, sorry?

In most cases, however, the EDIT link should be on the proper domain ...

Here is the updated patch.

I mean that URL rewrites generally mean that EDIT goes to the canonical domain.

This is actually a nasty problem, because the node might appear on a different domain, and the editor would be able to edit in one context and not another. I suspect that might lead to more confusion for editors than the original issue reports.

Really, what the current check does is say "Can this editor edit this unpublished node, regardless of domain context?" The patch changes that behavior to "Can this editor edit this unpublished node on this domain?"

I fear that second condition may confuse people too much to be a default behavior. So I'm not sure that this is a bug, but instead a feature request that needs some consensus.

Thank you for clarifying, I see what you mean.

... the node might appear on a different domain, and the editor would be able to edit in one context and not another.

I investigated with the Domain Source module enabled and setting a node to have a "source" (canonical) domain.

When a user is NOT assigned to a source domain but assigned to ANY OTHER domain viewing the node, the EDIT link there causes them to switch to the source domain, to edit the node.

After saving their changes, they're viewing the node at the source domain - not the original domain where they came from. I think this is the problem. They're presented with the 'Access denied' message on the source domain, because in this example, as it relates to the 'View unpublished content on assigned domains' permission, they are not assigned to the source domain.

If transferred to a source domain to edit content, can a user be transferred back to the original domain upon saving changes? This could work with Domain Source module in general.

I think this patch brings access to unpublished nodes and published nodes more in line. Instead of Domain Strict, you can just use published status to limit anonymous node access.

Status:Needs review» Needs work

This sounds right to me, looking at it again. Could really use a test.

StatusFileSize
new659 bytes

Attached updated patch for Domain 7.x-3.4. As it stands with the patch on here, we have a bright side and not-so-bright side:

Bright:
- Patch restricts access to unpublished content to only the unpublished content the user is assigned to. Which I thought brings unpublished and published node access more in line, in terms of managing access. And restricting / providing node access to anonymous users means just using unpublished / published node status instead of Domain Strict altogether.

Not-so-bright:
- With the Domain Source module enabled, a user may encounter an Access Denied message. Suppose a piece of content is assigned to a user's domain. This piece of content has also been assigned a different source domain. User is able to view and edit that piece of content. However, if the user is not assigned to the source domain, as it relates to the 'View unpublished content on assigned domains' permission with this patch, that will produce the Access Denied message after editing the content when they're transferred to the source domain and attempting to view the content from the source domain.

Maybe the user should be transferred back to the original domain they were on after submitting their edit. I thought this could work with the Domain Source module, but I don't use the Domain Source module often enough, so more thoughts on this could be helpful.

Status:Needs work» Needs review