Last modified: 2011-03-13 18:05:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 3693 - Re-enable previewing with GET requests
Re-enable previewing with GET requests
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
PC Windows 2000
: Lowest minor (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2005-10-13 07:27 UTC by Nick Jenkins
Modified: 2011-03-13 18:05 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Patch to re-enable previewing with GET requests (500 bytes, patch)
2005-10-13 07:28 UTC, Nick Jenkins

Description Nick Jenkins 2005-10-13 07:27:03 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: )

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.
Comment 1 Brion Vibber 2005-10-13 07:27:50 UTC
There was never any deliberate support for this.
Comment 2 Nick Jenkins 2005-10-13 07:28:08 UTC
Created attachment 988 [details]
Patch to re-enable previewing with GET requests
Comment 3 Nick Jenkins 2005-10-13 07:39:19 UTC
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?
Comment 5 Nick Jenkins 2005-11-29 06:21:20 UTC
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.
Comment 6 Brion Vibber 2006-02-14 06:23:00 UTC
Just a quick note; this is unsafe on wikis with raw HTML mode enabled.
Comment 7 Nick Jenkins 2006-02-14 07:51:22 UTC
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?
Comment 8 Brion Vibber 2006-02-14 08:20:58 UTC
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.
Comment 9 Brion Vibber 2009-07-19 23:04:40 UTC
Going ahead and closing this out. Doesn't seem to be super-popular and on general safety principle I recommend against allowing it.
Comment 10 Splarka 2009-07-20 03:56:43 UTC
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:

Note You need to log in before you can comment on or make changes to this bug.