This feature is implemented in the WikiFeeds extension.
http://opensource.case.edu/trac_projects/MediaWikiHacks/changeset/131
Source at http://opensource.case.edu/svn/MediaWikiHacks/extensions/WikiFeeds/trunk/Spe...
If private feeds are enabled (not default behavior), the first time you go to Special:WikiFeeds, a token is generated. There is still no way to regenerate the token, but that is simple enough to implement, if enough people ask.
Enjoy.
Gregory Szorc gregory.szorc@gmail.com
On 3/11/07, Titoxd@Wikimedia titoxd.wikimedia@gmail.com wrote:
As I was stuck in a traffic jam the other day (yeah. interesting place to think about MediaWiki stuff :P), an idea for adding RSS/Atom feed support for watchlists (as requested on Bug 471) came to me. I have no clue how feasible it is, so I'm just throwing the suggestion to gather comments. :)
Currently, the method the bug fixes use is to create a login cookie or something similar for the RSS feed, which then faces authentication issues. However, I thought it would be easier to provide a *previously-authenticated* session token, which then is just plugged into any feed aggregator (a la Google Calendar, to point to a similar implementation).
The way it would be done is like this:
Our unhappy user wants to have a create a feed for his watchlist.
The user clicks on [[Special:Watchlist/feed]] (or another URL), which
then generates a random 128-character string. This URL is stored somewhere in the database; perhaps as a user_feed_token field in the user table.
- [[Special:Watchlist/feed]] returns the string, and gives the unhappy
user a link, of the following format:
http://en.wikipedia.org/w/index.php?title=Special:Watchlist&target=%7B%7... }&token={{token}}
The unhappy user adds the link to his aggregator.
The aggregator displays the watchlist.
The unhappy user becomes happy.
Watchlist data is obviously private; as a result, the token should be able to be reset by the user if necessary, and only one token should be active at any time, like it is done with email confirmation tokens. Also, the strength of the token should be at least 128 characters, but it can be more if necessary. I'm not sure whether to use the username or the user ID of our happy/unhappy user; I thought the ID number would be more cryptic, but that's minor. If the token is wrong, then the request fails gracefully; no "wrong token error" is required.
Anyways, what do you all think? Comments? Flamebait?
Titoxd.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l