TAC and Views RSS
I have a situation to which I have developed a couple of solutions. However, colleagues believe that we are still missing something. I could use any input the community can share.
Plaftform: Drupal 5.14
Data Structure
- We have a large amount of published nodes in the form of news articles, reports, etc.
-
Registered users purchase subscriptions and are given access to view the full body of certain nodes depending on what they have subscribed to. This is controlled through TAC.
-
ANY user (including anonymous) can view a preview or teaser of the node. This is controlled through a custom module.
-
We want to build an RSS feed for members so they are notified when new content in their subscription is posted. The module we are going with is Views and Views RSS.
Problem
Views RSS utilizes the db_rewrite_sql() hook to allow TAC to restrict access to nodes. When an RSS server contacts our server to check for new data, it is obviously not logged in and thus Views RSS only returns nodes visible to anonymous users.
Proposed Solutions
Option #1: Assigning an unrestricted role to the user when viewing an RSS feed.
In the argument handler code in the view UI, I add the following code:
global $user;
$user->roles[5] = 'temporary rss access';
...Role ID 5 is actually a role that has been setup to have access to all terms and thus all nodes. By assigning this role to the user before the view creates the list, it will return all nodes that meet the view criteria.
I then have a hook_exit() function to remove the extra role from the $user object. The views rss theme fires this hook after rendering the view.
We are worried about the exposure that assigning a "view all" role to an anonymous user gives us.
Option #2: Cutting out a custom solution from Views.
The second option is to write a custom solution where I can create the SQL query, ignoring the TAC addition, thus allowing me to pull all nodes. With this we obviously lose the power of Views and the security that comes with Views, Views RSS and TAC.
My colleagues are certain that the situation is common enough that there is another solution that does not involve hacking out portions to create a custom module or assigning full access to anonymous calls. Does anyone have any other ideas?
- Chris