Page MenuHomePhabricator

Watchlist RSS feed should use 301 redirect to change token on every view
Closed, DeclinedPublic

Description

Author: paxcoder

Description:
[Difficul to subscribe]
"My preferences -> Watchlist" can be used to set or acquire a hash which is said there to be used to subscribe to the "My watchlist" feed. However, this is still a manual process described in a separate page (http://en.wikipedia.org/wiki/Wikipedia:Syndication#Watchlist_feed_with_token) not linked to. It should be automatic - the moment one generates a hash, it should appear as a feed link on "My watchlist" page instead of it offering to subscribe to global "Recent changes" as it does now. The temporary fix might be providing the above link on the "My preferences -> Watchlist" page.

[Security suggestion]
Security feature: You could improve the feed security by regenerating a hash each time one requests the feed. Judging by "My preferences -> Watchlist", generating a new, random, non-repetitive hash is not a problem. The support in feed readers could be achieved by a redirection using an HTTP 301 status code ("Moved permanently"), with the new link including the regenerated(new) hash. This would, in turn, result in a feed reader updating the URL.
In short: Client requests a feed using a link with the hash. If the hash is valid, it gets regenerated, and the client gets redirected to a page with a URL containing the new hash. Next time, the client requests the feed with a new hash, and the process is repeated.

Thanks.


Version: unspecified
Severity: normal

Details

Reference
bz20840

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 10:51 PM
bzimport set Reference to bz20840.
  • This bug has been marked as a duplicate of bug 471 ***

ayg wrote:

(In reply to comment #0)

[Difficul to subscribe]
"My preferences -> Watchlist" can be used to set or acquire a hash which is
said there to be used to subscribe to the "My watchlist" feed. However, this is
still a manual process described in a separate page
(http://en.wikipedia.org/wiki/Wikipedia:Syndication#Watchlist_feed_with_token)
not linked to. It should be automatic - the moment one generates a hash, it
should appear as a feed link on "My watchlist" page instead of it offering to
subscribe to global "Recent changes" as it does now. The temporary fix might be
providing the above link on the "My preferences -> Watchlist" page.

Yes, I added the feature in a very bare-bones way and hoped someone else would pitch in with some UI to make it more useful. If anyone wants to submit patches, I'll probably be willing to review them, although maybe not immediately.

[Security suggestion]
Security feature: You could improve the feed security by regenerating a hash
each time one requests the feed. Judging by "My preferences -> Watchlist",
generating a new, random, non-repetitive hash is not a problem. The support in
feed readers could be achieved by a redirection using an HTTP 301 status code
("Moved permanently"), with the new link including the regenerated(new) hash.
This would, in turn, result in a feed reader updating the URL.
In short: Client requests a feed using a link with the hash. If the hash is
valid, it gets regenerated, and the client gets redirected to a page with a URL
containing the new hash. Next time, the client requests the feed with a new
hash, and the process is repeated.

Do you have reason to believe that all feed readers actually update the URL they've saved if served a 301 response? Certainly browsers don't usually do that for bookmarks. It sounds like it would be unexpected behavior.

paxcoder wrote:

This bug is now marked a duplicate of some ancient bug which is said to be "solved", so this automatically is marked solved as well.
But it's not. The first part is obviously not solved, I can't see even a quick fix implemented (albeit I'm looking at Wikipedia). The first part doesn't even resemble bug 471. The second part is similar, but not the same. Not a "duplicate". I see now I can "reopen" it, so I'm going to do that, but if you mark it solved again, I'm not going to argue here. You do as you please. But I for one, would like to see a usable way to feed-read the watchlist.

ayg wrote:

(In reply to comment #3)

This bug is now marked a duplicate of some ancient bug which is said to be
"solved", so this automatically is marked solved as well.

Bug 471 was filed a long time ago, but reclosed very recently. Check the dates of the most recent posts there.

But it's not. The first part is obviously not solved, I can't see even a quick
fix implemented (albeit I'm looking at Wikipedia). The first part doesn't even
resemble bug 471.

FIXED means fixed on trunk, i.e., the development version of the code, not live on the site. The fix will show up on Wikipedia eventually, although possibly only in a few months. We don't have a separate status for "fixed but not yet live", since that would be a pain to maintain -- usually, hundreds or thousands of changes go live at once, and all corresponding bugs would have to be tracked down and updated.

The second part is similar, but not the same. Not a
"duplicate".

I've changed the summary to address the second part. I'm closing WONTFIX. Not only is it unclear whether using 301s would work even in basic cases, as I said in comment 2, it will definitely break if someone wants to use multiple feed readers. If you disagree on this second part -- not the difficulty of subscribing, which was fixed -- then please feel free to reopen and explain your reasons.

paxcoder wrote:

You did a mistake in renaming it. The primary issue is nr.1 here. The second just tags along.
Meh. Gone.

ayg wrote:

Well, it doesn't really matter what the bug is named. The first issue is fixed in r57119, as noted at bug 471 comment 62, and the fix will go live on Wikipedia eventually. The second issue is WONTFIX. Is that okay?

paxcoder wrote:

Oh. Ok then. Will wait for it.
But if that is true, and readers really do not react on moved permanently, I agree. Bug closed.