Last modified: 2008-05-28 09:15:09 UTC
(Component is wrong, AssertEdit doesn't seem to be in the component box yet.) According to [[Special:Version]], [[mw:Extension:Assert Edit]] is installed on enwiki (at least), but it doesn't appear to do anything at the moment; the URL referenced should cause an assertion failure, but instead acts as it would if the extension weren't installed. I couldn't cause an assertion failure with any other URL I tried either; not with /w/ or /wiki/ URLs, nor with any of the six assertions mentioned on the extension description page. I haven't tried on wikis other than enwiki.
The assertions are only checked when you hit the "edit" tab, since bot frameworks tend to bypass the page view, and grab the content directly from the edit view. You will currently get the expected error it you view http://en.wikipedia.org/w/index.php?title=Main_Page&action=edit&assert=false
It works for normal editing, but ironically not for API editing, where it's most needed. When parsing page HTML, a bot can learn that it has logged off by looking up JS variables, but there is no such easy method for API.
(In reply to comment #2) > It works for normal editing, but ironically not for API editing, where it's > most needed. When parsing page HTML, a bot can learn that it has logged off by > looking up JS variables, but there is no such easy method for API. > It looks like the API doesn't set the global request object, so the extension doesn't have access to parameters from the URL. It's probably necessary for the API to do something like "$wgRequest = $this->getMain()->getRequest()" somewhere, or have some other way of passing these arguments to the extension.
Assert Edit uses the AlternateEdit hook, which probably shouldn't even be in the API edit codepath. The extension should be fixed to use the APIEditBeforeSave hook instead. $wgRequest IS set in the API, though, look at api.php:74
I'm not sure why it doesn't work then, although I obviously haven't looked too carefully at the API yet. It looks like APIEditBeforeSave hides the normal request, and replaces it with a new one for the save, so that may not work unless it pass unrecognized options to the extension.
(In reply to comment #5) > I'm not sure why it doesn't work then, although I obviously haven't looked too > carefully at the API yet. It looks like APIEditBeforeSave hides the normal > request, and replaces it with a new one for the save, so that may not work > unless it pass unrecognized options to the extension. > You're right: it seems I've *deliberately* done that for hooks inside EditPage. Probably best to do that only after APIEditBeforeSave is run. Fixed in r35472
