Page MenuHomePhabricator

Re-enable previewing with GET requests
Closed, DeclinedPublic


Author: nickpj

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: )

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.

Version: 1.5.x
Severity: minor
OS: Windows 2000
Platform: PC



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 8:51 PM
bzimport set Reference to bz3693.
bzimport added a subscriber: Unknown Object (MLST).

There was never any deliberate support for this.

nickpj wrote:

Patch to re-enable previewing with GET requests


nickpj wrote:

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?

nickpj wrote:

Comment on attachment 988
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'])) {

  1. These fields need to be checked for encoding.
  2. Also remove trailing whitespace, but don't remove _initial_
  3. 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.

nickpj wrote:

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.

herd wrote:

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: