The problem at hand is that when Features are used to create content types Drupal registers Features as the content type's module which means that access control for example is being met by features_access() function.
The use-case is that while Features are great to export/import content type and other entities it may very well be required to control real access to the content type in question (remember that besides 'create', 'delete' and 'edit' there's also 'view' access which sadly there's no permission for).

Without this patch, to control access to view/load a specific content type would be only possible by:
1. patching and making changes to features_access()
2. implement logic using the node_access system which is really an overkill.

The provided patch hands the access control to whatever modules that wish to implement the required hook and in that sense it plays well with others and truly provides modular access control.

Files: 
CommentFileSizeAuthor
#13 features--node-access.patch1.04 KBmalcomio
Test request sent.
[ View ]
#12 features--node-access.patch1005 bytesmalcomio
Test request sent.
[ View ]
#9 features_access.patch843 bytesmalcomio
Test request sent.
[ View ]
#1 extend_node_content_type_access-1332244-1.patch820 byteslirantal
Test request sent.
[ View ]

Comments

StatusFileSize
new820 bytes
Test request sent.
[ View ]

Status:Needs work» Needs review

anyone willing to comment?

Status:Needs review» Needs work

It is trivial to go into the hook_node_type() implementation and swap out 'features' for the current module name. It might even be possible to have that be cooked in to how the node type is exported.

No need for strange workarounds.

@Grayside
Ah? but then it requires to modify the feature code after it was created... and what will happen in successive re-create of the feature?

It's not a "strange workaround" it's called modularity and provides other modules to hook into the access system of features which is an exported module code.

See if hook_node_type_alter() works for you.

Status:Needs work» Closed (won't fix)
  • this is not relevant to d7 (since there is a hook_node_access that anyone can use)
  • there's a reasonable, standard way to do it (May need a patch; there was a bug with changing module key, but I think it got commited).
  • There's also hook_node_records, etc.

thanks

Status:Closed (won't fix)» Active

I'd like to re-open this. I know that this issue isn't a problem for D7, but for those of us still using D6 (and who really don't want to enable the weighty node permissions system), this is still a problem. I've worked around it with the code here, as I personally think this patch is closer to how D6 is "supposed" to work. Can this be considered for inclusion in the D6 version?

<?php
function features_access($op, $node, $account) {
 
// Allow the feature that owns the node type to determine access permissions
 
module_load_include('inc', 'features', 'features.export');
 
$modules = features_get_default_map('node');
 
$type = is_string($node) ? $node : (is_array($node) ? $node['type'] : $node->type);
 
$access_function = (function_exists($modules[$type] . '_access')) ? $modules[$type] . '_access' : FALSE;
  if (
$access_function) {
    return
$access_function($op, $node, $account);
  }
  else {
    return
node_content_access($op, $node, $account);
  }
}
?>

It might also be prudent to modify features_perm() to not include the standard create/delete/edit permission definitions for a node type if the owning feature implements hook_access().

Thoughts?

I like #7

StatusFileSize
new843 bytes
Test request sent.
[ View ]

I've changed #7 slightly for coding style - here's a patch

Status:Active» Needs review

Status:Needs review» Reviewed & tested by the community

#7 does a fine job of solving the problem, TY. Use of hook_access() in Features-created modules is going through our QA dept right now. The patch is solid when applied against 6.x-1.2.

Edit: I should add that we've tested both with and without the use of a node access module (content_access).

StatusFileSize
new1005 bytes
Test request sent.
[ View ]

My team did some performance testing of the patch in #9, and for low traffic sites, the patch should be fine, but we did see a performance impact.

Here's a new patch which caches the features node map

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new1.04 KB
Test request sent.
[ View ]

After more testing, we realised that this was causing problems with creating content in certain cases, so here's a revised patch.