Last modified: 2011-06-07 21:36:28 UTC
This is an action doing "write".
raising to 'normal'
We did the same to action=markpatrolled (bug 24418). This needs to happen soon, prone to abuse and could lead to vandalism when people unwatch important pages from third party sites. Raising to High and setting milestone to 1.18
CC-ing iAlex who also fixed the token for markpatrolled.
Building tokens into the FormlessAction framework would probably be the cleanest way to achieve this.
Adding dependency on bug 29067. The script in the front-end to ajax-watch things was already rewritten for 1.17 to use the API instead. So the front-end should be trivial (adding a post/get parameter for the token). Created bug 29067 for the API part. The non-javascript fallback (index.php?action=(un)watch) also needs is, which I guess is the scope of this bug.
* Clean up in r88511. * Switching to POST (since that's what the API needs now (bug 29070, r88522) and adding error handling in r88527. * Passing token parameter in r88554 (via mw.user.tokens, introduced in r88553); Fixed!
API users and users on the wiki using the AJAX-button are covered. Looks like we haven't patched index.php?action=(un)watch yet though. The security problem is still there. Reopening..
Why was this fixed in reverse order? It should have been fixed first in html, then in javascript (which could then take advantage of the token in the url).
Should be assigned to somebody else, won't have time to fix this the coming two weeks.
(In reply to comment #8) > Why was this fixed in reverse order? > > It should have been fixed first in html, then in javascript (which could then > take advantage of the token in the url). I disagree about it being the reversed order. They are two distinct methods using different protocols and different tokens. One is through the API, which scripts and programs use. This is through a POST request with a standard token that can be retrieved from the API. The other is on-wiki through index.php. This is trough a GET request with a stronger token (on-wiki action links can only be GET and thus need a little stronger protection, I'm not sure if that is still the case, but that's the way we did it with patrol and rollback links in index.php, so it makes sense to that here as well). Both are independent and need to be fixed seperately. AFAIK the order doesn't matter. The reason the on-wiki javascript-watch button is using the token already and the html isn't, is because the javascript button is using the API (not index.php), so I adjusted it in advance (since the API watch-module was already done) and the javascript wouldn't be done differently if it were fixed the other way around (ie. index.php first and api.php later) -- In the past many gadgets ajaxified functions by making a ajax-request to the index.php url (which they scrapped from the page) and giving an "OK" message through dom-manipulation by checking the http response code or by digging through the HTML of the response. This isn't very clean and doesn't provide very complete or accurate response to the user, and one could argue whether this is efficient (as it would cause MediaWiki to render an entire page rather than just a simple request with a short JSON response, that is more machine readable and language/wiki independent). Therefor the ajax-watch was switched to using the API a while ago.
(In reply to comment #10) > (In reply to comment #8) > > Why was this fixed in reverse order? > > > > It should have been fixed first in html, then in javascript (which could then > > take advantage of the token in the url). > > I disagree about it being the reversed order. They are two distinct methods > using different protocols and different tokens. > > One is through the API, which scripts and programs use. This is through a POST > request with a standard token that can be retrieved from the API. > > The other is on-wiki through index.php. This is trough a GET request with a > stronger token (on-wiki action links can only be GET and thus need a little > stronger protection, I'm not sure if that is still the case, but that's the way > we did it with patrol and rollback links in index.php, so it makes sense to > that here as well). > > Both are independent and need to be fixed seperately. AFAIK the order doesn't > matter. > > The reason the on-wiki javascript-watch button is using the token already and > the html isn't, is because the javascript button is using the API (not > index.php), so I adjusted it in advance (since the API watch-module was already > done) and the javascript wouldn't be done differently if it were fixed the > other way around (ie. index.php first and api.php later) > > -- > > In the past many gadgets ajaxified functions by making a ajax-request to the > index.php url (which they scrapped from the page) and giving an "OK" message > through dom-manipulation by checking the http response code or by digging > through the HTML of the response. This isn't very clean and doesn't provide > very complete or accurate response to the user, and one could argue whether > this is efficient (as it would cause MediaWiki to render an entire page rather > than just a simple request with a short JSON response, that is more machine > readable and language/wiki independent). > > Therefor the ajax-watch was switched to using the API a while ago. There is index.php?action=ajax but I don't know where we are using it.
(In reply to comment #11) > There is index.php?action=ajax but I don't know where we are using it. Hopefully nowhere, it's deprecated in favour of the API.
Fixed in r89545
(In reply to comment #10) I didn't suggest doing the javascript watch through the UI, I only refered to the token.
