Last modified: 2011-03-13 18:04:44 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 20840 - Watchlist RSS feed should use 301 redirect to change token on every view
Watchlist RSS feed should use 301 redirect to change token on every view
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Watchlist (Other open bugs)
unspecified
All All
: Lowest normal (vote)
: ---
Assigned To: Aryeh Gregor (not reading bugmail, please e-mail directly)
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-28 08:09 UTC by Luka Marčetić
Modified: 2011-03-13 18:04 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Luka Marčetić 2009-09-28 08:09:09 UTC
[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.
Comment 1 Brion Vibber 2009-09-28 19:16:54 UTC

*** This bug has been marked as a duplicate of bug 471 ***
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-09-29 13:20:23 UTC
(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.
Comment 3 Luka Marčetić 2009-09-30 19:38:44 UTC
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.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-09-30 19:57:57 UTC
(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.
Comment 5 Luka Marčetić 2009-09-30 20:04:09 UTC
You did a mistake in renaming it. The primary issue is nr.1 here. The second just tags along.
Meh. Gone.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-09-30 23:00:24 UTC
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?
Comment 7 Luka Marčetić 2009-10-01 09:41:02 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links