Page MenuHomePhabricator

Cannot read watchlist feed if mediawiki is private, even using the watchlist token
Open, LowPublic

Description

I have a wiki (1.24.0) which is only readable to authenticated users:

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;

Unfortunately this also makes it impossible to access the watchlist feed.

<?xml version="1.0"?>
<api>
  <error code="readapidenied" info="You need read permission to use this module" xml:space="preserve">

IMO this is wrong. There's watchlist token exactly for that.
In the MediaWiki-General channel on IRC I was told to open a bug report.

Event Timeline

Tessus raised the priority of this task from to Needs Triage.
Tessus updated the task description. (Show Details)
Tessus added a project: MediaWiki-General.
Tessus changed Security from none to None.
Tessus subscribed.
Aklapper edited projects, added MediaWiki-Watchlist; removed MediaWiki-General.

I hoped that the priority was a Normal. Especially since this bug makes it impossible to use RSS feeds with private wikis.

I second Tessus: I think this is not a low priority. Especially since Mediawiki already doesn't accept logins from RSS (https://www.mediawiki.org/wiki/Thread:Project:Support_desk/feed_from_private_wiki). To me the community surrounding mediawiki seem like the kind of people who would see the importance of being able to use automated tools to manage ones web feeds.
Could someone direct me somewhere to explain what that watchlist token is actually for?

I think this is not a low priority.

Anybody who plans to work on this can increase the priority field (which reflects reality and does not cause it) and is encouraged to correct my initial setting of "low priority".
Generally speaking, you could either reach out to developers and convince them to work on this, or try to come up with a fix.

Aklapper renamed this task from cannot read watchlist feed, if mediawiki is private to Cannot read watchlist feed if mediawiki is private: Use the watchlist token.Mar 27 2015, 11:26 AM
Tenbergen renamed this task from Cannot read watchlist feed if mediawiki is private: Use the watchlist token to Cannot read watchlist feed if mediawiki is private, even using the watchlist token.Mar 27 2015, 2:53 PM

Thanks Aklapper for explaining the priority field. I had misunderstood it to be some sort of triage.
You changed the title of this as well, adding "Use the watchlist token". I changed the wording slightly because on first read that looked to me like using the token might solve the issue, which it does not.
Regarding coming up with a fix, I think this might be first a philosophical problem and only second a technical one. For sake of argument, let's assume I were to work out how to add an exemption to the API that omits login requirement for token access to watchlist. I would expect there to be resistance from whoever implemented this to not work that way in the first place. When I tried to find out how the RSS feeds are supposed to work, documentation is kind of slim to start with, so how would one find out the intended functionality and/or a place to discuss it? I have a reasonably good understanding of how the content side of wikipedia deals with this sort of thing, but have not contributed to the code side.
Thanks! T

For sake of argument, let's assume I were to work out how to add an exemption to the API that omits login requirement for token access to watchlist. I would expect there to be resistance from whoever implemented this to not work that way in the first place.

Not really. The default in the API is to deny access if the user doesn't have read access since that's usually the correct action, so it's much more likely that this situation was simply overlooked.

Overriding this default is simple enough for action=feedwatchlist, just override the isReadMode() method in the API module to return false (ideally with a code comment that explains why it's being overridden). In this particular case, you'd also need to add checks to the module's execute() method to throw an appropriate error message if the effective user doesn't have 'read' permission.

I was confronted with the same problem as the original poster: a "closed" wiki of which I want to make the feed of recent changes available. Anomie's hint lead me to the following solution (thanks a lot!). Add the following lines to 'includes/api/ApiFeedRecentChanges.php' right after the class definition on line 27:

/**
 * Indicates whether this module requires read rights
 * @return bool
 */
public function isReadMode() {
        return false;
}

This will un-require read permissions for just this one API-module, leaving everything else untouched. It looks pretty safe from my point of view but I do not have any experience with these things. Any comments welcome!

Sm8ps, I tested this a while ago and it works great. Thanks for your help!

What is the status on this? After 3 years somebody might have been able to come up with a process.

I mean it is not very complicated to fix this issue as mentioned by @Sm8ps, but a MediaWiki developer has to accept it and add it to the code (or I can open a PR). This change should also go into ApiFeedWatchlist.php.
As long as you have a valid token, you should be able to access the RSS feeds. It doesn't matter, if it is an open or closed wiki.

Please let me know how to proceed.

Thanks for the comment! You are very welcome to use developer access to submit any proposed code changes as a Git branch directly into Gerrit which makes it easier to review and provide feedback.
If you don't want to set up Git/Gerrit, you can also use the Gerrit Patch Uploader. Thanks again!

I hoped I could just create a PR on GitHub. I didn't really want to create yet another account....

But I'll have a look at it next week. It's not just creating another account, but learning the dev process for this project and so on. Coding takes me 50 seconds. The admin crap around it 2 weeks.

Anyway, it seems that gerrit is the main development process and I want to add some stuff to the RedisBagOStuff as well, so I guess I will have to learn how to use gerrit.

@Tessus: Unfortunately that is currently the situation - we prefer to be in control of our infrastructure, so to say, which also has obvious disadvantages.
If anything on https://www.mediawiki.org/wiki/Gerrit/Tutorial is unclear, please feel free to ask - happy to help!