I've added into the head branch some quick preliminary stuff for supporting syndication feeds, adding an RSS option to Special:Newpages.
Access like so: http://....?title=Special:Newpages&feed=rss
It should be quite easily extendible to other QueryPage-based special pages (indeed, a change to QueryPage could probably make it available for every one of them), and to other similar feed formats such as Atom (subclass in Feed.php). These feeds at least for now don't include page text or anything, just titles, dates, edit comments, and links.
This replaces the old (and broken for a long time) rdf/recent.phtml... once it's working smoothly in all the places it's appropriate we'll also want handy visible links to the syndication feeds, of course.
-- brion vibber (brion @ pobox.com)
So, this is a Good Thing.
I'm wondering how unreasonable it would be to syndicate watchlists. I think we'd have to have some kind of authentication, and I don't know how well that fits in with the RSS framework.
~ESP
Evan Prodromou wrote:
I'm wondering how unreasonable it would be to syndicate watchlists.
Might be an interesting idea, but may raise privacy concerns. These RSS feeds must therefore be deactivatable.
I think we'd have to have some kind of authentication, and I don't know how well that fits in with the RSS framework.
It is not possible in general to authenticate an RSS feed. Of course Wikipedia could require a cookie or a HTTP Auth before it will show you the RSS feed, but that makes it pretty much useless because most RSS readers don't support this. In particular, a lot of RSS readers -- such as LiveJournal -- handle RSS feeds as a fundamentally public resource and cannot allow any authentication to be sent with it.
Timwi
Timwi timwi@gmx.net writes:
It is not possible in general to authenticate an RSS feed. Of course Wikipedia could require a cookie or a HTTP Auth before it will show you the RSS feed, but that makes it pretty much useless because most RSS readers don't support this. In particular, a lot of RSS readers -- such as LiveJournal -- handle RSS feeds as a fundamentally public resource and cannot allow any authentication to be sent with it.
I'm currently thinking about the same problem for a personal Web site. The approach I'll probably choose is some hash in the URL. For example a hash of the User name and the Password hash. The "XML" or "Syndicate" or whatever-button will then link to the rss.php?user=user&id=HASH page. There I can easily check if the HASH is correct for the specified user.
Every RSS reader I have used so far supported query strings.
Regards Patrice
Patrice Neff wrote:
Timwi timwi@gmx.net writes:
It is not possible in general to authenticate an RSS feed. Of course Wikipedia could require a cookie or a HTTP Auth before it will show you the RSS feed, but that makes it pretty much useless because most RSS readers don't support this. In particular, a lot of RSS readers -- such as LiveJournal -- handle RSS feeds as a fundamentally public resource and cannot allow any authentication to be sent with it.
I'm currently thinking about the same problem for a personal Web site. The approach I'll probably choose is some hash in the URL. For example a hash of the User name and the Password hash. The "XML" or "Syndicate" or whatever-button will then link to the rss.php?user=user&id=HASH page. There I can easily check if the HASH is correct for the specified user.
That seems quite clever - if a user want their feed to be public, they can just give out the URL, and if they want it private again, they just change their password.
However, I can see two problems with it. Firstly, if the hash is known, then the password might not be too difficult to crack anymore (because you can just do it locally). Seconlyd, users are probably generally too stupid to handle it correctly. Some people will put such a hashed URL into a public RSS reader (e.g. LiveJournal) and then complain that other people can reed their feed.
Admittedly, the latter problem is probably not quite as bad on Wikipedia.
Timwi timwi@gmx.net writes:
However, I can see two problems with it. Firstly, if the hash is known, then the password might not be too difficult to crack anymore (because you can just do it locally). Seconlyd, users are probably generally too stupid to handle it correctly. Some people will put such a hashed URL into a public RSS reader (e.g. LiveJournal) and then complain that other people can reed their feed.
Admittedly, the latter problem is probably not quite as bad on Wikipedia.
That's a valid argument. A dictionary attack might be a problem especially considering the problem that most users still use very weak passwords. So additionally we could add a date of the last change into the string where we calculate the hash from. I see that the user_touched field already exists in the database. Could we use this? So for example a calculation like $hash=sha1($user_id.$user_name.$user_password.$user_touched)
Of course then we would need to give a user-friendly error message once the user can not be authenticated. I'm thinking about a single valid RSS item saying that the user could not be authenticated and explaining the fact, that a new URL must be used after every edit.
Or if we don't have too many options in the settings yet, we could make including the $user_touched variable optional... :-)
Regards Patrice
On Sunday 07 March 2004 14:50, Patrice Neff wrote:
Timwi timwi@gmx.net writes:
However, I can see two problems with it. Firstly, if the hash is known, then the password might not be too difficult to crack anymore (because you can just do it locally). Seconlyd, users are probably generally too stupid to handle it correctly. Some people will put such a hashed URL into a public RSS reader (e.g. LiveJournal) and then complain that other people can reed their feed.
Admittedly, the latter problem is probably not quite as bad on Wikipedia.
That's a valid argument. A dictionary attack might be a problem especially considering the problem that most users still use very weak passwords. So additionally we could add a date of the last change into the string where we calculate the hash from. I see that the user_touched field already exists in the database. Could we use this? So for example a calculation like $hash=sha1($user_id.$user_name.$user_password.$user_touched)
Of course then we would need to give a user-friendly error message once the user can not be authenticated. I'm thinking about a single valid RSS item saying that the user could not be authenticated and explaining the fact, that a new URL must be used after every edit.
I don't think that's a good idea. But more information could be added that rarely or never changes and is known to user only, for example, date of account creation (if it is known) and user's preferences.
On Mar 7, 2004, at 23:09, Nikola Smolenski wrote:
On Sunday 07 March 2004 14:50, Patrice Neff wrote:
Timwi timwi@gmx.net writes:
Some people will put such a hashed URL into a public RSS reader (e.g. LiveJournal) and then complain that other people can reed their feed. [snip]
[snip] I'm thinking about a single valid RSS item saying that the user could not be authenticated and explaining the fact, that a new URL must be used after every edit.
I don't think that's a good idea. But more information could be added that rarely or never changes and is known to user only, for example, date of account creation (if it is known) and user's preferences.
This seems like an impractical road with major usability problems.
It's been suggested in the past to allow users to mark their watchlists as public, so for instance someone could go to http://en.wikipedia.org/wiki/Special:Watchlist/Brion_VIBBER to see my watchlist (if I marked it as public). A public watchlist could then also be syndicated as RSS.
That's clean and simple: opt-in, so you're aware that your watchlist isn't 100% private, and we don't have to worry about constructing walls and barriers to keep people from accidentally letting it slip out (or get in themselves!)
-- brion vibber (brion @ pobox.com)
"BV" == Brion Vibber brion@pobox.com writes:
BV> It's been suggested in the past to allow users to mark their BV> watchlists as public, so for instance someone could go to BV> http://en.wikipedia.org/wiki/Special:Watchlist/Brion_VIBBER to BV> see my watchlist (if I marked it as public). A public BV> watchlist could then also be syndicated as RSS.
I was thinking the same thing.
~ESP
"BV" == Brion Vibber brion@pobox.com writes:
BV> It's been suggested in the past to allow users to mark their BV> watchlists as public, so for instance someone could go to BV> http://en.wikipedia.org/wiki/Special:Watchlist/Brion_VIBBER to BV> see my watchlist (if I marked it as public). A public BV> watchlist could then also be syndicated as RSS.
This would also make the perennial favorite "Who's watching this page?" feature practicable, too.
~ESP
Are you all aware of how the "Related Changes" to "List of voting systems topics" is being used at http://www.electorama.com? I don't know how Rob does it, but it would probably be simplified by a standard RSS feed. It would be perfect for any themed site to hook people into a WikiProject. Imagine a Korean portal showing the last five edits to "list of topics related to Korea", etc.
Brion Vibber wrote:
I've added into the head branch some quick preliminary stuff for supporting syndication feeds, adding an RSS option to Special:Newpages.
Access like so: http://....?title=Special:Newpages&feed=rss
It should be quite easily extendible to other QueryPage-based special pages (indeed, a change to QueryPage could probably make it available for every one of them), and to other similar feed formats such as Atom (subclass in Feed.php). These feeds at least for now don't include page text or anything, just titles, dates, edit comments, and links.
This replaces the old (and broken for a long time) rdf/recent.phtml... once it's working smoothly in all the places it's appropriate we'll also want handy visible links to the syndication feeds, of course.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org