On 16/09/05, Timwi <timwi(a)gmx.net> wrote: Yes, that is what has been suggested in the past; the general consensus usually emerges that it would be nice to also provide a minimal piece of security, such as a "secret" URL token generated when the user opts in. But the main point is, no-one's implemented it yet. -- Rowan Collins BSc [IMSoP]

On 16/09/05, Thomas Gries <mail(a)tgries.de> wrote: Yes - or my comment #8 on that bug, which reads in part: I don't really see the need for e-mail addresses to be involved, unless that happens to make the code much simpler for some reason - the decisions of whether to register an e-mail address and whether to activate an RSS watchlist are completely unrelated. The way I pictured it, the "secret" token would just show up on the preferences page once the user opted in. -- Rowan Collins BSc [IMSoP]

On 16/09/05, Ævar Arnfjörð Bjarmason <avarab(a)gmail.com> wrote: *sigh* Sorry, that's a rude start, but this conversation seems doomed to go round in circles every few months - until someone implements a decent solution, I guess. See, for example, http://mail.wikipedia.org/pipermail/wikitech-l/2004-December/026562.html - where Brion points out that even if most RSS readers can use HTTP authentication, MediaWiki can't, so it's not really all that helpful. Also, remember that RSS readers come in all shapes and sizes, including web-based aggregators, and telling people to type their username and password into those as plain text (i.e. in the URL) is *far* worse than just making their watchlist public. Hence the need for an authentication token that's not the user's normal password, and hence it might as well just be at the end of the URL, rather than in the special "user:pass@host" format. And in case anyone's about to mention some RSS readers supporting cookies (because they're built into browsers): http://bugzilla.wikimedia.org/show_bug.cgi?id=471#c12: I remain convinced that the only reasonable solutions, which will apply to *all* RSS readers, are: 1) allow users to opt-in to RSS, and make sure they realise this means anyone can look at it 2) allow users to opt-in, and give them a pseudo-secret URL when they do If anyone can come up with anything equally flexible but more secure, fine; if not, anyone interested in this feature should work on implementing it on those principles. (IMHO) -- Rowan Collins BSc [IMSoP]

On 17/09/05, Ævar Arnfjörð Bjarmason <avarab(a)gmail.com> wrote: [snip] Yes, but saying "just use HTTP authentication" makes it sound like this is somehow the easy option. Implementing a whole new authentication scheme into MediaWiki just to let people have RSS watchlists isn't something I'd call easy... Besides, given the range of readers people use to access RSS feeds, is HTTP-Auth even the best way to go? Think of a web-based aggregator, for instance, where the user-agent connecting to the MediaWiki server is essentially a bot on the server, with no visibility to the actual user - the user will have no chance to respond to an authentication challenge. So the obvious alternative is to tell them to put their username and password into a "user:pass@host" format, to see if that works - but that means entering the password to their whole account in plain text, on a site which may or may not be all that trustworthy. So instead of using the normal password, we let them use a special "watchlist password", which since they can just use copy-and-paste might as well be a randomly generated token. And then, to avoid things not recognising the "user:pass@host" format, we can just put that random token at the end of a special URL (it's not really logging them in anyway); in which case, we don't need to bother implementing HTTP Authentication after all. And so we've come round full circle - a special URL containing a randomly generated token. -- Rowan Collins BSc [IMSoP]