Still current, got a complaint on internal.wikimedia.org and confirmed.

Culprit seems to be a bogus permission check in FeedUtils::formatDiffRow():

		//NOTE: Check permissions for anonymous users, not current user.
		//      No "privileged" version should end up in the cache.
		//      Most feed readers will not log in anway.
		$anon = new User();
		$accErrors = $title->getUserPermissionsErrors( 'read', $anon, true );

On a fully-restricted site, anonymous viewers wouldn't be able to reach a feed at all, so this makes no sense -- you just end up with a feed that's just missing content for all the people who *can* read it.

This might make sense on a partially-restricted site, where the feed is accessible but some pages can't be read by anon visitors... in which case you'd still be exposing various edit information that you likely ought not to.

dieudonne wrote:

(In reply to comment #1)

Still current, got a complaint on internal.wikimedia.org and confirmed.

Culprit seems to be a bogus permission check in FeedUtils::formatDiffRow():

//NOTE: Check permissions for anonymous users, not current user.
//      No "privileged" version should end up in the cache.
//      Most feed readers will not log in anway.
$anon = new User();
$accErrors = $title->getUserPermissionsErrors( 'read', $anon, true );

On a fully-restricted site, anonymous viewers wouldn't be able to reach a feed
at all, so this makes no sense -- you just end up with a feed that's just
missing content for all the people who *can* read it.

This might make sense on a partially-restricted site, where the feed is
accessible but some pages can't be read by anon visitors... in which case you'd
still be exposing various edit information that you likely ought not to.

It's good to feel understood :-)

Any chance to see an evolution about that ?

Could an existing extension help turn around the problem ?

Brion,

Culprit seems to be a bogus permission check in FeedUtils::formatDiffRow():

Do you suppose you could check out removing the bogus permission check and see what happens?

dieudonne wrote:

Thank you Mark for your interest in this problem.

Does anyone have an idea of the evolution of this bug ?

(In reply to comment #4)

Does anyone have an idea of the evolution of this bug ?

I'll bring it up in our next bug triage.

Experimental extension checked in today: http://www.mediawiki.org/wiki/Extension:FeedsFromPrivateWikis

Not planning to solve this for 1.18

dieudonne wrote:

(In reply to comment #7)

Not planning to solve this for 1.18

Any chance it can be solved with 1.19 ?

Or does any one know how to make http://www.mediawiki.org/wiki/Extension:FeedsFromPrivateWikis compatible with 1.18 ?

(In reply to comment #8)

Or does any one know how to make
http://www.mediawiki.org/wiki/Extension:FeedsFromPrivateWikis compatible with
1.18 ?

I just tried it in 1.18 and didn't see any obvious problems. But I did not test thoroughly. What problems are you seeing?

dieudonne wrote:

(In reply to comment #9)

(In reply to comment #8)

Or does any one know how to make
http://www.mediawiki.org/wiki/Extension:FeedsFromPrivateWikis compatible with
1.18 ?

I just tried it in 1.18 and didn't see any obvious problems. But I did not
test thoroughly. What problems are you seeing?

Same problem as with the other Feed : it gives only the title of the modification, not it's content.

dieudonne wrote:

Did anybody try with MW 1.19 ?