With r31184, I provided a way for wiki admins to turn off the syndication feeds totally, when they desire. My knowledge of syndication feeds is limitted but if there is no standard way to authenticate inside feed readers, then I think the only solution available is to turn them off when there are good reasons (such as when read permission is restricted).

palaniappanc wrote:

The IRC conversation about this bug

Attached:

Created attachment 4675
Human readable version of the same IRC log

Attached:

soxred93 wrote:

Hmm...even when using a version of MW downloaded a few weeks ago, turning read to false turns off the feed as well. Are you sure you are using the latest version of MediaWiki?

Works for me.

http://office.wikimedia.org/w/index.php?title=Special:Recentchanges&feed=rss

The reporter seems to be under the impression that the URL is insecure because
it doesn't contain a password. The opposite is true. Access to the URL is
authenticated by cookies. Putting the user's password in the URL would expose
it to accidental leaks.

Note that if Special:Recentchanges were in $wgWhitelistRead, then the RSS feed
would be available. So don't put Special:Recentchanges in $wgWhitelistRead.

The feed is served with CC:private and Vary:cookie, so there is no cache-based
leak.

palaniappanc wrote:

Soxred93,
The version I'm using is 1.11.1. I downloaded it about 7-10 days back. I can upload the .tar.gz file here if you want to check. And yes, I had turned read to false. $wgGroupPermissions['*']['read'] = false;

(In reply to comment #4)

Hmm...even when using a version of MW downloaded a few weeks ago, turning read
to false turns off the feed as well. Are you sure you are using the latest
version of MediaWiki?

Tim Starling,
I am not under the impression that the URL is insecure because it doesn't contain a password. At that point in the IRC chat, I remembered that some feeds contain a username and password in the URL to allow content to be served to registered users. But since I was able to read the content via my RSS reader though the Special:Recentchanges page's content was supposed to be protected (can't read it without logging in and $wgWhitelistRead is set to false - see below) AND the URL didn't contain any username/password, I made that comment.

I'm not saying that u/ps in URLs is a secure method. But I do believe that serving protected content only in the presence of a username/password is more secure than serving that content anyway (discounting the fact that the u/p could be discovered by someone else).

I've pasted the relevant parts of LocalSettings.php and DefaultSettings.php below. Am I missing something here?

LocalSettings.php:
#permissions
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['user']['read'] = true;
#because of RSS bug
$wgFeedLimit=0;

DefaultSettings.php

1. Pages anonymous user may see as an array, e.g.:
2. array ( "Main Page", "Special:Userlogin", "Wikipedia:Help");
3. NOTE: This will only work if $wgGroupPermissions['*']['read']
4. is false -- see below. Otherwise, ALL pages are accessible,
5. regardless of this setting.
6. Also note that this will only protect _pages in the wiki_.
7. Uploaded files will remain readable. Make your upload
8. directory name unguessable, or use .htaccess to protect it.

$wgWhitelistRead = false;

(In reply to comment #5)

Works for me.

http://office.wikimedia.org/w/index.php?title=Special:Recentchanges&feed=rss

The reporter seems to be under the impression that the URL is insecure because
it doesn't contain a password. The opposite is true. Access to the URL is
authenticated by cookies. Putting the user's password in the URL would expose
it to accidental leaks.

Note that if Special:Recentchanges were in $wgWhitelistRead, then the RSS feed
would be available. So don't put Special:Recentchanges in $wgWhitelistRead.

The feed is served with CC:private and Vary:cookie, so there is no cache-based
leak.

Is your feed reader also your browser? (Eg, Safari, Opera, Firefox.) In this case, your login session in the browser will apply just as much to the feed reader, and you're just seeing an authenticated page because you're in an authenticated session.

It's possible that some third-party feed readers also in some way share cookies with associated browsers (perhaps by piggybacking on Internet Explorer), so check into that.