Add permissions to disable RSS feeds

+1 vote

I think we should be able to control RSS feeds using the access control page, so we can control who is able to receive a RSS feed (nobody in my case) on a "per module"-basis.

I agree - this would be a good feature.

You can use .htaccess to disable access to your main feed, something like:
RewriteRule ^node/feed$ [G,L]

just as long as you put it before the other rules...

not sure why this went to the user system. I blame my touchpad.

I agree, sites should not be forced to have an RSS feed.

Here is a possible solution to the problem. It doesn't really "disable" RSS feeds, but it allows the option to have "0" items per RSS feed. So, you'll still have RSS feeds, but they will not have real content in them. I've done limited testing of this on my 4.7 test site and it seems to work. I don't know what undesirable effects it might have... perhaps there is a good reason why "0" isn't an option w/o this patch?

I still think it would be nice to have the option to disable RSS feeds. But until then, I'll be using this patch.

I'm changing this from a 'normal' feature to a 'critical' feature. Just my opinion... we'll see what Drupal developers think of it.

-Steve

+1 I also need this.

I don't think this is critical. I also don't understand why somebody would not want to have a rss feed. It is just another way of presenting your content.

The patch should display "disabled" if you chose 0 items.
The rss header should also not be produced if the number of items is 0.

killes,
I see your point -- thank you for your comments. My reason for not wanting the RSS feed is that I believe there was a time when RSS feeds were not affected by Taxonomy Access Control. TAC has been extensively modified, and is now (at least in 4.7) affecting what is in the RSS feed. So, that's good news!
I don't know enough about Drupal to make the changes you suggested to the patch. I'm sorry.
-Steve

+1 for being able to disable RSS. Yes, RSS is "just another way of presenting your content". And not everyone wants to present their content in that way. Especially if you're a consultant, you may want to make that an optional feature. Or the RSS icon may look hideously ugly in your theme. Or you may want to insist that people come to the site and see the full story as it's presented in that format, along with the GoogleAds module in the sidebar.

There's lots of reasons why one may not want RSS. It should be an admin option that's easily toggleable, not a mandatory feature.

Here's an alternative patch that implements the ability to enable/disable view content feeds through access control. It hides the link on the header, the syndicate block and locks the menu_callback used to define the rss.xml path.

User who don't have permission to read feeds will get a nice 403 page instead ...and, of course, you'll get a nice entry in the log.

Please, review.

+1. Lots of good reasons have been posted.

Just submitted a patch at http://drupal.org/node/71563 to allow users to exclude certain node types from RSS feeds. Could choose all types, but it would still generate a 0 item RSS feed like stated above. Might work for some peeps...discuss amongst yourselves.

I agree that this should be implemented as a permission. I'd use the term 'RSS feed' rather than 'content feed'. The patch looks good but isn't complete. Other modules need updating too.

http://drupal.org/node/62007

This issue has a patch adds the perm RSS feed and applies it to node/feed and rss.xml

This issue is marked as a "feature request" where as the above issue is marked "bug report". So I'm not sure if this issue should be closed by way of status:duplicate ?

Hi,
just for the case, here i have a reason why having no rss feed is sometimes good.
Our site has a provate calendar with some public entries also (node_privacy by role).
In the rss ALL of the events appear, even those which are private. So it would be good to switch it completely off.
Of course another task could be to make the rss generating part of drupal take care of access setting by privacy by role and other modules... but i think this would be more complex to do.

thanks, greetings
sammy

Duplicate of http://drupal.org/node/62007

tried the patch here and doesnt seem to do anything..

i do get the new access control item.. but RSS feed icons still which show and still work.

my guess is they are created by category module and this match only works for std drupal node types??? which in my case isn't of much use.

looked at the other 62007 link and it seems to be for Drupal 5... anyone have a patch for 4.7 that controls this for the entire site...

also, (killes).. can't imagine why anyone would suggest "no reason to turn this off".. duhhh.. cuz my client doesnt want it there... nuff said.

Peter...

but until a real patch comes along.. this code in page tpl at least removes the RSS icon

$content = preg_replace('%<a href=.* class="feed-icon">.*</a>%', "", $content); 

A solution I've found, is overriding the default template function for the feeds, in template.php:

function phptemplate_feed_icon($url) {
return '';
}

BTW, you could put anything inside, and customize the feed url, the icon, etc.

Greetings,

Mariano.

Please give your feedback at: http://drupal.org/node/230710

Cheers mmg83 - just just what I was looking for.

I can confirm that this works in 5.7.

Reasons for disabling it:

1. seems a little buggy
2. budget not willing to support theming & troubleshooting for feature, but not willing to have something sloppy on the site
3. I never meant anyone to see my taxonomy, but pow there it is.

+1 on this from me. My client is not running a blog or any kind of community site and simply has no need for the feed, and neither do they want it.

Resetting to CNW as this issue was filed before #62007: Add 'access RSS feed' permission to control access to RSS feeds

i'm sorry, but this is really absurd - since at least 2005 people in this forum only want a little checkbox to deactivate the feeds and want to use views instead or whatever ... and yearly they have to bring their arguments again ... why is it so difficult? i don't understand ...

greetings momper

momper, none of the people who wanted it have supplied an updated patch in the past several months, or a suggestion of how the UI might look, whether it should be a checkbox on the 'post settings' page, whether it should be split between the rss.xml feed and taxonomy (or per taxonomy vocabulary), or for all feeds, whether there should be a permission. Or for that matter how Drupal might handle permissions for RSS feeds when they're going to be viewed by RSS clients rather than browsers.

If you'd really like this feature, one or other of the above might help to encourage a patch.

Also, the title of this issue isn't very descriptive, changed it.

Marked #62007: Add 'access RSS feed' permission to control access to RSS feeds as a duplicate of this issue.

sorry, if i crabbed a little bit ... it was a hard day ... i would enjoy to fix this problem, but unfortunately i have not the skills to do this. maybe the start should be a practical solution ("checkbox on the 'post settings' page" or something with the user rights) to make it into 7.x-dev. and later start with the fine tuning. but i don't know, how complex which solution is ...

@momper

It isn't that easy. The RSS generation is deep and un-separated in the system module. The feed generation in Drupal is crufty. My personal goal is to get #230710: Centralized module to control feeds and feed types ready to go in some form or another.

Now that Unstable Drupal releases are live I think the process will be easier.

@samirnassar - this sounds complicate - I hope it comes out well - i will track your efforts ...

thanks and greetings momper

Marked #322101: Disable RSS feed as a duplicate of this issue.

Hi, As I see, this is 3 years old request. I would suggest to implement a base solution now, like #322101: Disable RSS feed, to give a nice and useful solution for the user, and when the complex solution is ready (#230710: Centralized module to control feeds and feed types), to implement that.
What do you think?

PS. +1 vote

I think what we need here is the following, could happen in more than one issue:

1. Use real menu paths for RSS feeds. Blog module has an explicit entry for feeds, taxonomy and node modules don't.
2. When we have real hook_menu entries for feeds, we can add a new permission.

Then, if you don't want any RSS feeds on your site, you just don't give any users that permission. How fine grained we'd make it (node/feed, blog/feed, blog/uid/feed, taxonomy vocabularies?) is up for discussion.

Ok. I developed a permission based RSS access. I have attached the patch.
I'm waiting for your feedback.

Some remarks:
- I have left the original solution in the code. It is good, when the user wants to turn off the rss feed completely.

- I have rewritten the menu path in the node module, and I have modified in the taxonomy.
The new rss paths for node types:
* feed/node: all node
* feed/node/uid: all node created by a user
* feed/nodetype (for example feed/article or feed/page): all the given node type
* feed/nodetype/uid: all the given node type created by a user
Maybe it is too much, you can decide.

- I have created new permissions:
* Access RSS content: for the rss.xml
* Access node RSS content: for feed/node and feed/node/uid
* Access Article/Page/etc RSS content: for the given node type
* Access taxonomy RSS content: for the taxonomy
I was thinking about just use one permission, but it is more flexible solution. And the user easily can turn off the RSS completely with the original solution.

Let's not introduce more feeds - kittens will be injured by not making that a separate issue. In this issue, let's focus just on fixing RSS permissions only.

Ok, so we have the technical solution: permissions. Reducing the scope of the issue. Everything else implemented by #40 is out of scope, please open a new issue for node feed pages.

Ok. I would like to summarize, what would be a good patch:

- One new RSS permission in the node module: "Access RSS content "
The admin can disabled or enabled the RSS feed (individually for each user roles) with this new permission.
The new RSS permission can disabled/enabled all (!) of the RSS feed (node, blog, taxonomy ...).
If it is disabled, the RSS feed pages (e.g. /rss.xml) give "Not found" error, and the RSS feed icon (feed.png) isn't visible.

- I suggest, to modify the RSS admin page too (/admin/content/rss-publishing). Let's allow the "Number of items in each feed" to be 0 too. It would be good, if the admin wants to publish the RSS feed without content (so the users can subscribe, but the RSS feed may starts later).

- And I suggest to put a link on this RSS admin page: "Check here if you want the RSS Feed to be enabled or disabled globally", and the link would points to the Permission page (/admin/user/permissions).

If it was ok, I would create the appropriate patch.
I'm waiting for your feedbacks.

Here is a starter patch.

Ok. I have reviewed and tested the patch, and seems everything is all right.

What I missed is the '0' element in the 'Number of items in each feed' selection (admin/content/rss-publishing). I have created a patch for this (no other differences between the two patches).

What about the two (for blog and node) permissions that share the same title:

+ 'title' => t('Access frontpage feed')

I know the actual permission is different, but this seems like it will be confusing.

Ok, I have modified the patch. Please, check.

(+1)

This is important for several sites. Drupal is a very useful tool for internal sites, intranets, etc., in situations where this is a concern. Should be left to the admins of each site to determine the appropriate state for RSS.

Is here anybody, who can approve (or decline) this patch? :)
If you think, this patch needs work, I will do it. If it was ok, it would be good to implement to the next Drupal version.

See: http://pastebin.ca/1258476

Access aggregated blog feed- this should probably be "Access site blog feed" or "Access main blog feed" - 'aggregated' could easily be confused with the aggregator module.

It'd be better to have the main RSS feed provided by a menu callback, and do access based on that, probably out of scope for this patch though.

Also, nothing in here for taxomomy.module - which provides RSS feeds too.

Marked #217706: Setting to disable RSS completely as a duplicate.

+1

would need this too

This is a feature and will only be applied to Drupal 7.

+1
it is not good for my needs and my theme, I'd like the icon rests only in the address bar of the browser

I have created a patch according to #39, #52.
Please, test it.

This is the patch #58 with tests.

Made a few changes in patch context code only to be current with -- and able to apply to -- HEAD.

For those who need a quick fix for Drupal 6, implementing hook_menu_alter() should do the job.
Disable 'rss.xml' completely:

/**
 * Implementation of hook_menu_alter()
**/
function mymodule_menu_alter(&$callbacks) {
  $callbacks['rss.xml']['access callback'] = FALSE;
}

If you want finer permissions, implement hook_perm() and then in hook_menu_alter() change access callback and access arguments.

+1 for this.

I hope people like foripepe keep working on resolving the Drupal RSS issues. This has been a very long standing feature request. In fact, this one was opened more than 3 years and 8 months ago!

This was a feature request for version x.y.z when it was opened in 6 Aug 2005.

Then on 6 June 2007, it was moved to version 4.7

On 6 March 2008, target version was bumped up to 7.x by samirnassar based on a parallel work #230710: Centralized module to control feeds and feed types samirnassar has been doing which is also targeted for D7.

The length of time and the duplicates and discussions surrounding RSS issues like #62007: Add 'access RSS feed' permission to control access to RSS feeds opened 5 May 2006 (almost 3 years ago) indicate that many drupal users want better drupal handling of RSS in at least 3 areas from what I see:

a> The abiity to turn it off entirely
b> The ability to implement security in the feeds
c> The ability to implement/choose what type of feed(s) to serve (RSS, Atom....)

I hope the designers and gods of drupal here and in the Drupal User Experience Project http://www.d7ux.org/ would take notice and help in adding these much needed "features" that people have been requesting for.

Subscribing to this issue.

I have created a new patch. Please, test it.

Let's enable this permission for all users in the install profile. I think it would be bad to disable RSS feeds by default.

I have created a new patch. It's enable the RSS feed by default.
Please, test.

The documentation of blog_feed_user_access still needs to be updated, I think. It also looks like that function could be simplified -- do we really need all those checks? I don't think that check belongs in the access call back.

I was thinking about the blog_feed_user_access() function. Originally I was created it to get the same permission like the blog view. But I think you are right, it is possible the make the code more simple (and delete this function).

I have created a new patch. Please, test it.

@Dries: The access control for blog RSS feeds has to be similar to the one we perform when displaying the blog listing page. But, we can easily refactor blog_page_user_access() so that it accepts a permission parameter:

function blog_page_user_access($account, $permission) {
  // The visitor must be able to access the site's content.
  // For a blog to 'exist' the user must either be able to
  // create new blog entries, or it must have existing posts.
  return $account->uid && user_access($permission) && (user_access('create blog entries', $account) || _blog_post_exists($account));
}

Then, we define blog menu callbacks this way:

  $items['blog/%user_uid_optional'] = array(
    'title' => 'My blog',
    'page callback' => 'blog_page_user',
    'page arguments' => array(1),
    'access callback' => 'blog_page_user_access',
    'access arguments' => array(1, 'access content'),
    'file' => 'blog.pages.inc',
  );
  $items['blog/%user/feed'] = array(
    'title' => 'Blogs',
    'page callback' => 'blog_feed_user',
    'page arguments' => array(1),
    'access callback' => 'blog_page_user_access',
    'access arguments' => array(1, 'access rss content'),
    'type' => MENU_CALLBACK,
    'file' => 'blog.pages.inc',
  );

I just came across comment #66.

I'm using Drupal 6.12 and would like to turn off the RSS Feeds during testing.
As a newbie I was wondering if someone can explain. Where do the changes suggested in comment 66 need to be made or do I need to create a patch to apply?

Thanks,

Izzy

I have created a new patch, according to #74.

This looks acceptable, however, there has to be an update function that enables this permission so there is no regression for existing sites.

I'd probably write 'RSS' instead of 'rss' in the permission name.

Keep up the good work.

Kindly let have RSS feed for books, enabled or disabled.
Let the site admin determine which default content types can have RSS on or off
and whether auth users can override these in their edit area.
Please also have a backport to Drupal 6.
Please see the diagram.

Change in the diagram to add option for Book

RSS options can also be logically added in Administer › Content management › Content type › Workflow settings. A checkbox below

Published
Promoted to front page
Sticky at top of lists
Create new revision
Enable RSS

This should ideally work like a two-way electrical switch, if you put it off here it also goes off in Administer › Content management › RSS publishing

The added advantage of putting it in Administer › Content management › Content type
is that RSS on or off can be more granular for comments. For example, profiles are made private by users in many sites these days, putting off comments RSS for profile can be helpful while keeping those on for forum. Sooner or later users ( auth users or site members) are going to demand this.

@Dries

"there has to be an update function that enables this permission so there is no regression for existing sites."
Ready.

"I'd probably write 'RSS' instead of 'rss' in the permission name."
All human-readable texts are 'RSS'. As I checked the permission names are always small, so I left them small.

@kaakuu

I think these are good ideas, but they are out of scope of this issue.

This seems like cluttering up the system with if statements, whereas if the solution to this problem was to break syndication out to its own module like proposed in #230710: Centralized module to control feeds and feed types, it could be handled there and be shutoff altogether if desired.

Subscribing to this issue.

Just a question for those who have submited code suggestions to change drupal core code:
Why not, if possible, build a MODULE to disable the RSS feed globaly?

Its that viable?

No new features will be added to 6.x.

alexcunha,

I just use hook_menu_alter and delete the rss.xml link.

Re-rolling the patch to take into consideration #300993: User roles and permissions API. Moved the system.install permissions changes to default/expert.install. I kept the system.install update because that still seems like the place to do it. (?)

Fixed the taxonomy and blog offsets. Here we go.

Oh dangit. I forgot one line. Let's try this again.

I ran it through my own simpletest, and it seemed to pass. Let's see if there are any exceptions this time.

I hate patches with system.install update_N()...

Updated patch before the last one falis...

Can there be a module for Drupal 6x ( and Drupal 5x ) based on the above so that any individual user can opt to turn off his RSS feed from the account/profile edit page ? If this can be kindly done it will be of immense help.

Re: #92, see comment #66 in this very issue.

edit: in other news, re-tested the patch today, still works. Now we just need someone higher up the food chain to review and get this into core before it turns into a 6-7 year old issue.

@mradcliffe - thanks to you. The first part of that is okay but I do not know how to implement that second part so that the auth user sees a checkbox or radio-button to put ON_OFF his rss feeds. I meant a module for that, and will keep this posted here if any willing and benevolent coder notices this and gifts us an easy module.
So that, it can be just click and install for us :)

Thanks.

+1, Subscribing. Don't have enough technical skill (yet) to help, but really would like to see a solution to this (for v5.x). Thank you.

@95, the current task is to get this into Drupal 7. There are some work arounds for disabling the rss menu items via a custom module.

Things look good so far (I hope). We're still passing tests on the patch. Although not having any official review yet since before DrupalCon is a bit worrying.

Updated patch.

Drupal is a good CMS and has great developers too.

Sorry that i'm a n00b and don't know the coding standards of drupal, but why do you don't implement that into drupal 6?

There is a patch with 16 lines of code changes (http://drupal.org/node/322101) e.g. for drupal 6.

Is that such an excessive code change to do for a "problem" that is discussed nearly 4 years now?

I don't understand...

@devrand: As a policy, Drupal does not add features to a stable version. Period. Even small ones. New features are added to the in-development version only. The current stable version gets bug/security fixes only. That keeps the current stable from becoming a moving target and being "unstable". Even "small" features could introduce new bugs or translation changes or other mysterious things that could cause unpredictable behavior.

@Crell: thanks for your explanation - OK, policies are necessary and policies are a must have, full ack.

But adigio - it's getting rediculous!

Many people are using drupal 6, many people are using drupal 5.

If drupal 7 is getting released (maybe) at the beginning of 2010, there are still a lot of users/admins which will using drupal 6. For drupal 7 themes needs to be adjusted, modules or whatever. It needs at least(!) one or two years more if people will be migrating to drupal 7! That's my position from the admin point of view, where you want a stable and a long tested and used great CMS - as drupal is...

However, it can't be that difficult to translate the following words (for the above patch i was pointing out) into other languages:

1. checkbox with: "RSS Feed enabled"
2. Annotation with: "Check here if you want the RSS Feed to be enabled."

It can't be that difficult that users and admins must be a addicted (since over 4 years!) of a policy which is in some facts far away from the real world, where something is a must have - for customers - and not for developers.

I don't see any arguments to put this although into older drupal versions, but maybe drupal is getting more and more bureaucratic. I thought that only commercial products are affected from those discussions, but it seems that i'm on the wrong way, when i was thinking of open source...

but maybe drupal is getting more and more bureaucratic. I thought that only commercial products are affected from those discussions, but it seems that i'm on the wrong way, when i was thinking of open source...

Helpful tip: Thinly veiled insults will rarely get you what you want. That's true in commercial products as well as in open source, and in just about every other part of life. Really, you've just destroyed any credibility you may have or any inclination I have to be patient with you as a new user. Congratulations.

However, for the sake of others who may read this thread, I will explain it to you anyway.

The reason we don't allow string changes in stable versions is that existing translations will then be broken. You will suddenly have the entire site translated in German except for this one string. That's effectively an API change for translations, and we do not break APIs in stable releases. Developers would be pissed if we broke an API in a bugfix release, and rightly so. Translators feel the same way about their APIs. The fact that some people run Drupal sites for a long time and expect them to NOT change APIs out from under them is the very reason we do that.

Plus, as I said above, adding features in a stable release introduces the potential for more bugs, more API changes, and Drupal otherwise shifting around underneath you when you expected it to be a stable, known target. That's bad on many levels.

If you want this patch to get committed, whining that Drupal developers aren't real open source developers because they have a process that they follow is counter-productive. Either review the patch so that it has a better chance of getting into Drupal 7 or get out of the issue. Right now you're just wasting the time of the very people who could help push this patch closer to completion.

Help or shut up, but don't whine and insult.

In #85 above
request for version 6.13 was changed to 7.x-dev saying "No new features will be added to 6.x."

In #66 above a solution has been attempted for drupal 6x. But it does not provide all the codes or a module that can be implemented.

To many users, including actual end users, this is a ''critical bug'' affecting privacy and personal security, particularly those in social networking. Many users cannot use drupal with this absent, including other absent privacy features - they do not complain here as they may have already shifted away.

Thus to them or me this is not asking for a new feature but making a feature already present free of bugs or more usable.

If #66 is okay it means minor additions or alterations. Changelog of Drupal 6.14 show changes which have been more intensive in nature and of debatable nature whether those are bug or features. Question is whether we label this as bug, which it is to me but depends on others here for the label.

Easiest solution will be if some kind-hearted dev contributes a working module for drupal 6x.

Okay, let's get this patch back up to speed.

I'm an idiot. I forgot to check that. Working on a few things at the moment, but I should have this working in shortly.

Okay, this should work now. Tested patching and installing several times via clean drupal 7 cvs updates.

It seems to be failing because getDefaultFeedItemCount() does not take into account a user. It just returns the default number of feeds. Frankly, SimpleTest scares the hell out of me, so I don't think I can correct this myself. Hopefully someone else takes up the torch and corrects aggregator.test so that it has the correct behavior.

Subscribing

RE #104: Dang, this is still going on, huh? I posted #66 in the first place, so I guess I'll get to work on that Drupal 6 module then... Coming soon...

Looking forward to a solution. Subscribing.

* subscribing

Just wanted to turn off the RSS to test some new OG's on a production site (after development).

Strange that this feature is asked first in 2005, but not still implemented.

subscribing

The stopgap module, RSS Permissions, is now available for Drupal 6: http://drupal.org/project/rss_permissions

This is a new feature, so moving to D8.

Wait .. what? D8??? The first comment is made in 2005! When i post an issue for a feature in 2010, it will be granted in 2015????

@Lenn-art as noted in #117 you have a workable solution for D6 sites and I'm sure phpdiva would love to port the module to D7 as well. Drupal is a do-ocracy. Things don't magically happen. It takes people to create the patches and more people to have interest in helping review them and get them ready to be committed. If you've done more than request that this feature be added, my mistake, but if you haven't you don't really have any right to complain.

phpdiva: nice work

@Dave yes i'm aware that Drupal is do-ocracy (nice term ;)). Code doesn't grow on trees. But the request for this feature is done by user cursor already in 2005.

Thinking ahead to Drupal 8 and looking at the RSS Permissions module it would be great if all the various RSS feeds were somehow registered in a standard form. Right now they are all over the place, and who knows what we in contrib might do.

Maybe an API devoted entirely to organizing and allowing modules to publish their content as RSS.

+1 vote (Feature Request) for any type of control of the RSS feed functionality build in core.

@phpdiva Thank you very much for the RSS Permissions module Spasiba
Keep up the good work.

So it's been 5 years and we still can't disable the feed???

subscribing

Created a basic patch that adds a 'view rss feeds' permission and creates a radio button on the Web Services » RSS Publishing form.

Both anon and authenticated users have permission to access feeds by default.
With feeds disabled, rss.xml returns drupal_not_found() and RSS headers are not injected in pages.
The syndication block warns if feeds have been disabled.

There is no test case as yet.

Please don't RTBC your own patches.

I think we should consider moving RSS feeds (and the syndication block) into a dedicated module, although that might be hard to figure out where the integration lies, instead of adding the variable. It's the sort of thing that could live in lister module (if lister module gets in as a dedicated module).

I would agree that moving that out to the "hard coded core lists" module makes more sense than a permission. And once it's split off, it's easier to improve its UI and allow turning it off, etc. (Because the module itself could be turned off, we don't need to worry about the UI overwhelming people who wouldn't need it. We'd just turn it off entirely.)

Would it make sense to apply the patch anyway, so that the functionality is there and will then need to remain across moving it to a module of its own? Just to make it not fall by the wayside as it has from 4.7 until now.

Agreed that this should be a module

#127: 28337-norss-127.patch queued for re-testing.

127: 28337-norss-127.patch queued for re-testing.

So 8.1 or Closed (Won't fix)?

This issue is just plain redundant now, since all the core feeds have been replaced by default views installed by core modules.

Feed displays can have their access restricted by roles or permissions, or just deleted outright. Similary the feed icons can be controlled by the 'Attach to:' setting.

So effectively fixed by efforts elsewhere. I took 8.0.0-beta3 for a spin on simplytest.me to confirm all this.