https://bugzilla.wikimedia.org/show_bug.cgi?id=21912
--- Comment #7 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2009-12-29 20:28:25 UTC --- On reflection, agreed. I ended up doing the token thing as a quick hack to get the feature working with as little work as possible. We should just have a checkbox to enable/disable, that's it. The question is, what happens if the user wants to change the token because someone has stolen it? If we ignore this case, it all becomes very easy. Just hardcode the token to some hash of user_id + secret fixed global salt. But then you can't change the token for an individual user short of changing their user_id, so if anyone ever finds out what the token is, they can never safely enable watchlist feeds again. This is what prompted me to go with a manually-alterable token approach. Alternatively, what if the hash depending on user_password instead of user_id? Then all they'd have to do is change their password. This means your RSS feed breaks if you change your password, but maybe that's expected? I imagine most users don't change their password very often either. So here are a few possibilities: 1) Have a checkbox in preferences to disable watchlist feeds, and a button to generate a new token. Tokens are autogenerated and stored per-user, but not directly exposed in prefs. 2) Have a checkbox in preferences to disable watchlist feeds, and just use a hash of user_id + secret global salt. If a user's hash gets revealed, they can decide to either stop using watchlist feeds or let everyone see what's on their watchlist. (If the global salt becomes public somehow, it would have to be regenerated, so maybe random per-user hashes would still make more sense here, but that's an implementation detail.) 3) Have a checkbox in preferences to disable watchlist feeds, and use a hash of user_password + secret global salt. If a user changes his password, he has to update the link in his feed reader too. (If the global salt becomes public somehow, users' passwords would be vulnerable to much easier brute-forcing, so a per-user hash might be a good idea here too. In that case this is just (1), with changing your password instead of a separate button.) I guess I'm inclined to say (1) is best here, although it will require a bit more work than (2) or (3). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
