I went ahead and implemented a TODO item:

  • Using Node Api, create access restrictions whereby users can set nodes to be private,public or buddies only.

Attached is the module that does this (for me). I was unable to find a way to prevent unreadable entries from being displayed at all, and I only implemented it for blog entries. Changing the latter should be trivial, changing the former may be impossible.

CommentFileSizeAuthor
#10 buddies.tar.gz6.56 KBdreadwains
#1 buddyperms.tar_0.gz2.37 KBneale
buddyperms.tar.gz2.51 KBneale

Comments

neale’s picture

neale commented
Title: Buddy-based per-blogentry permissions » Zoikes! New version.
StatusFileSize
new buddyperms.tar_0.gz2.37 KB

Please do not use the original version!

The original version had a bug in which the only people who could view buddies-only posts were the people who set the poster as a buddy (not the people whom the poster had set as a buddy, which is what you'd expect.)

Here is a fixed version.

moshe weitzman’s picture

moshe weitzman commented
Title: Zoikes! New version. » access control for buddies

please provide a patch file if possible. see diff and patch page

neale’s picture

neale commented

Do you mean a patch to my original tar file, or do you mean that the original tar file should be a patch?

The original tar file is a whole new module, no existing code is modified. A patch file would take up more space and be more difficult to install :) For the fix, I thought it would be easier for folks to download a new tarball than a patch to the original one, seeing as how it's not part of drupal.

I'd be happy to provide a patch file if you still think I should upload one, but I'll wait until I hear back from you before doing it. I don't want to gunk up the file system :)

dreadwains’s picture

dreadwains commented

"I was unable to find a way to prevent unreadable entries from being displayed at all..."

Might it be possible to implement the hook_db_rewrite_sql hook in the buddyperms module to rewrite all node queries to look at the buddyperms permissions? If so, unreadable entries shouldn't be displayed anywhere, right?

moshe weitzman’s picture

moshe weitzman commented

very close ... the right way to access congtrol nodes is to use the 'node access api'. see http://drupaldocs.org/api/head/group/node_access

the patch here takes a different, less powerful approach.

dreadwains’s picture

dreadwains commented

I think ideally that this access control (and any other access control module probably) would prevent a user from ever knowing that a node even exists if they don't have access to it. This means it shouldn't show up in node listings, it shouldn't be included in counts and statistics, or anything. Given this, I see a couple of issues with using the node access API:

1) Range queries or queries that count rows in the node table cannot use the node access API to limit the results.
2) There is no way that I know of to enforce developers to check node access before displaying a node.

Could implementing hook_db_rewrite_sql address both of these issues?

Here's a quote from the node access API documentation:

"In node listings...hook_access() is not called on each node for performance reasons and for proper functioning of the pager system. When adding a node listing to your module, be sure to use db_rewrite_sql() to add the appropriate clauses to your query for access checks."

I'm a little unclear on the use of hook_db_rewrite_sql() vs. db_rewrite_sql():

1) Do we have to call db_rewrite_sql() explicitly for each query we write, or is it called automatically by db_query()?
2) Does db_rewrite_sql() invoke every implementation of hook_db_rewrite_sql()?

neale’s picture

neale commented

I've been playing around with the node access API, and it looks like it will only ever invoke the access hook defined in the module associated with the node. Here's the code in node.module's node_access function:

  $access = module_invoke(node_get_module_name($node), 'access', $op, $node);
  if (!is_null($access)) {
    return $access;
  }

Seem to me like unless I name my function blog_access, I can't hook into the node access API for blog nodes. Furthermore, the blog_page_user function being called when I tested this doesn't even use the node access API, nor does the node_view function that blog_page_user calls.

So rewriting the SQL would be the only way to do it, and I'll look into doing that. Someone please correct me, though, if I'm missing something, since in general I'm awful at SQL :)

moshe weitzman’s picture

moshe weitzman commented

see the bottom of node_access() that determines access control when the node->type module has not given any (the usual case).

dreadwains’s picture

dreadwains commented

I'm working on a solution that uses the hook_node_grants() instead of node_access() and it looks promising. It's tied in to a rewrite of the buddylist module I've done that organizes buddies into separate groups or lists. Ideally I could post a first draft of these modules next weekend.

dreadwains’s picture

dreadwains commented
Version: 4.6.x-1.x-dev »
StatusFileSize
new buddies.tar.gz6.56 KB

Sorry for the delay. I am posting two work-in-progress modules here.

1) buddies.module

This is a complete rewrite of the buddylist module. This is my first module so I rebuilt it from scratch in order to learn how to write modules. I renamed it so it wouldn't conflict with the existing module on my system (I wanted both as I was developing). I have not yet added the blocks back, or the feed. Basically the buddies page has a View and an Edit tab. On the Edit tab is where you create, delete and rename lists, and where you add and remove users from your lists. There is no longer a link from the user's page to be added to a buddylist. I also have not put in any functionality to see who has made you their buddy, nor is their any notification of being added or removed from lists. There are three permissions:

- view user buddy lists: All users have the right to see their own buddy lists, but this permission would give you the ability to see other users' buddy lists. I don't use this but it could be used to determine who can see which buddy lists they are on.
- create buddy lists: Gives a user the right to create buddy lists.
- administer buddy lists: Gives a user all rights to all buddy lists. I haven't provided a link to edit other users' buddy lists though. I don't know if this should be "maintain buddy lists", because I don't know what the difference is.

2) buddies_node_perms.module

This module is based on the node_privacy_byrole and nodeperm_role modules. It allows you to limit the viewing of nodes to certain buddy lists. Just like the node_privacy_byrole module, you need to go to the Settings page and enable the module their as well, in order to remove the global node grants in node_access, or it will not work.

These modules are not complete, but I think they should work. I would appreciate any feedback in terms of functionality or coding tips (not code format, I'll figure that out later). If the maintainer of the buddylist module wants to incorporate any of this functionality let me know.

robertdouglass’s picture

robertdouglass commented
Status: Active » Closed (won't fix)

dreadwains, thanks for all this great work. I've taken over maintaining the buddylist module and am adding features, but I'm hesitant to build a permissions system into it. I think that you could build a separate module that would use the buddylist's APIs or tables to do the job. Perhaps you could refactor your module above to be such a module? I'm marking this as "won't fix", since I don't see it as being the direction that the buddylist module itself will be taking. Let me know if you need help getting a new project set up for your new module.

-Robert