Last modified: 2011-03-13 18:05:04 UTC
At some point in the past 9 months a change to MediaWiki broke previewing using GET requests. Prior to this time it used to work fine (further details at: http://mail.wikipedia.org/pipermail/wikitech-l/2005-October/031833.html ) I will shortly attach a small patch which enables previewing using GET-only requests, but not saving using GET-only requests. My intention is to provide a useful middle-ground that provides both functionality and security.
There was never any deliberate support for this.
Created attachment 988 [details] Patch to re-enable previewing with GET requests
Re: There was never any deliberate support for this. I honestly didn't know it wasn't deliberate (how would I?), but nevertheless it did work, and it was useful, and I and others did use it. Call it an "accidental feature", if you like. I don't expect you or anyone else to deliberately support it, but if that accidental useful feature can be reinstated safely and used by crazy people like me, then why not?
The following pages are some more real-world redirect-creation examples that would have benefited, or will still benefit, from re-enabling this: * http://en.wikipedia.org/wiki/List_of_Melbourne_suburbs/table * http://en.wikipedia.org/wiki/List_of_Sydney_suburbs/table * http://en.wikipedia.org/wiki/Talk:List_of_Geelong_suburbs * http://en.wikipedia.org/wiki/List_of_suburbs_of_Canberra/table * http://en.wikipedia.org/wiki/Talk:List_of_Hobart_suburbs * http://en.wikipedia.org/wiki/Talk:List_of_Perth_suburbs * http://en.wikipedia.org/wiki/Talk:List_of_suburbs_in_Greater_Newcastle%2C_New_South_Wales
Comment on attachment 988 [details] Patch to re-enable previewing with GET requests >+++ includes/EditPage.php Thu Oct 13 16:51:59 2005 >--- ../virgin/includes/EditPage.php Thu Oct 13 09:48:27 2005 >@@ -207,7 +207,7 @@ > * @todo document > */ > function importFormData( &$request ) { >- if( $request->wasPosted() ) { >+ if( $request->wasPosted() || isset($_REQUEST['wpPreview'])) { > # These fields need to be checked for encoding. > # Also remove trailing whitespace, but don't remove _initial_ > # whitespace from the text boxes. This may be significant formatting. Update to swap "-" and "+", as they are/were wrong way around in the diff.
Just a quick note; this is unsafe on wikis with raw HTML mode enabled.
By raw mode, do you mean Wikis not running Tidy? Why are they vulnerable if this is re-enabled, as surely anything you can do with GET requests, you can also do with POST requests? (In fact, in some ways POSTS are a better attack vector, as they're not as obvious in the Apache logs as GET attacks.) Or to put it another way: why would they be unsafe with this, but safe currently?
No, I mean wikis with $wgRawHtml on, where you can use the <html> pseudotag to embed arbitrary HTML. Previews on POSTs could be protected with the edit token; I'm not sure offhand if they actually are (I know I did for the user-JavaScript and user-CSS special-case previews, which were what I originally added it for). Fulfilling this enhancement request requires that previews work on GET without a session-specific token, so for safety it needs to be disablable at least for those sorts of wikis.
Going ahead and closing this out. Doesn't seem to be super-popular and on general safety principle I recommend against allowing it.
There is action=parse in the API that returns the escaped rendered content. An extension, Special:ExpandTemplates, also currently allows both POST and GET. Eg: http://en.wikipedia.org/wiki/Special:ExpandTemplates?input=%3D%3DFoo%3D%3D%0A%0D%7B%7BREVISIONUSER%7D%7D+is+a+doodiehead#Foo