WordPress Trac: Ticket #10360: $_REQUEST's slashes may differ from $_GET/$_POSThttps://core.trac.wordpress.org/ticket/10360
<p>
$_REQUEST is re-created from $_GET/$_POST on line 51 of wp-settings.php
</p>
<p>
However, $_GET/$_POST/$_COOKIE are slashed ~ line 580, The end result is that <tt>$_POST['test']</tt> may not equal <tt>$_REQUEST['test']</tt> depending on the server setup, and content of such globals.
</p>
<p>
My suggestion would be to move both code blocks from where they currently are, and place them in about line 260. (Or alternativly, Just add $_REQUEST to the deslash/addslash code block..)
</p>
en-usWordPress Trachttps://core.trac.wordpress.org/chrome/site/your_project_logo.pnghttps://core.trac.wordpress.org/ticket/10360
Trac 1.0.1Denis-de-BernardyWed, 08 Jul 2009 09:32:53 GMTcomponent, milestone changed; owner sethttps://core.trac.wordpress.org/ticket/10360#comment:1
https://core.trac.wordpress.org/ticket/10360#comment:1
<ul>
<li><strong>owner</strong>
set to <em>ryan</em>
</li>
<li><strong>component</strong>
changed from <em>Administration</em> to <em>Security</em>
</li>
<li><strong>milestone</strong>
changed from <em>2.9</em> to <em>2.8.1</em>
</li>
</ul>
<p>
this seems rather blocking imo
</p>
TicketDenis-de-BernardyWed, 08 Jul 2009 09:36:26 GMThttps://core.trac.wordpress.org/ticket/10360#comment:2
https://core.trac.wordpress.org/ticket/10360#comment:2
<p>
Curious to know why $_REQUEST isn't slashed, alongside $_GET, $_POST and $_COOKIE...
</p>
Ticketdd32Wed, 08 Jul 2009 09:38:31 GMThttps://core.trac.wordpress.org/ticket/10360#comment:3
https://core.trac.wordpress.org/ticket/10360#comment:3
<p>
Probably because when that code was written, It was taboo to touch $_REQUEST (Or it was simply forgotten..)
</p>
<p>
That being said, I hate that plugins have come to expect slashed content..
</p>
TicketDenis-de-BernardyWed, 08 Jul 2009 09:53:15 GMThttps://core.trac.wordpress.org/ticket/10360#comment:4
https://core.trac.wordpress.org/ticket/10360#comment:4
<p>
yea. the real question will be what will happen if/when we drop the behavior, though... Imagine all of the security holes that we'll be introducing.
</p>
Ticketdd32Wed, 08 Jul 2009 10:24:51 GMThttps://core.trac.wordpress.org/ticket/10360#comment:5
https://core.trac.wordpress.org/ticket/10360#comment:5
<p>
most of the WP Private API has moved/started to move to expecting non-slashed data, Well, aside from those which retain the back-compat since they're called directly.
</p>
<p>
It is a shame that it'd introduce holes, but it'll happen one day..
</p>
TickethakreFri, 10 Jul 2009 11:18:20 GMThttps://core.trac.wordpress.org/ticket/10360#comment:6
https://core.trac.wordpress.org/ticket/10360#comment:6
<p>
Dropping "Request Abstraction" again. API Style. Should save us a lot of headaches w/o doing much bloat.
</p>
<p>
+1 for "Legacy code can stay legacy and fails sometime"
</p>
Ticketdd32Fri, 10 Jul 2009 11:21:10 GMTsummary changedhttps://core.trac.wordpress.org/ticket/10360#comment:7
https://core.trac.wordpress.org/ticket/10360#comment:7
<ul>
<li><strong>summary</strong>
changed from <em>$_REQUEST's slashes may differ from $_GEt/$_POSt</em> to <em>$_REQUEST's slashes may differ from $_GET/$_POST</em>
</li>
</ul>
<p>
Except its hardly Legacy, And is used more often in WP every version. Generally only or comparison of action args. Its rarely used for data which may include slashes, infact, pretty much unheard of.
</p>
<p>
there was a recent changeset which forces $_REQUEST to be $_GET + $_POST, so it removes most of the usual PHP-arguements against using $_REQUEST.
</p>
TickethakreFri, 10 Jul 2009 12:59:56 GMThttps://core.trac.wordpress.org/ticket/10360#comment:8
https://core.trac.wordpress.org/ticket/10360#comment:8
<p>
The argument against using $_REQUEST is taht, well using it disables you to determine of which the source comes from. So merging $_GET + $_POST into $_REQUEST still keep this argument.
</p>
Ticketvladimir_kolesnikovFri, 10 Jul 2009 20:54:25 GMTcc sethttps://core.trac.wordpress.org/ticket/10360#comment:9
https://core.trac.wordpress.org/ticket/10360#comment:9
<ul>
<li><strong>cc</strong>
<em>vladimir@…</em> added
</li>
</ul>
<p>
In brief:
</p>
<p>
If magic_quotes_gpc is on: $_GET, $_POST, $_COOKIE, $_SERVER and $_REQUEST will be slashed;
If magic_quotes_gpc is off: $_GET, $_POST, $_COOKIE and $_SERVER will be slashed, $_REQUEST won't.
</p>
<p>
And, $_REQUEST = array_merge($_GET, $_POST) does not take into account php.ini's variables_order variable and (for PHP 5.3.0), request_order variable.
</p>
<p>
BTW, throwing $_COOKIE out of $_REQUEST breaks phpBB.
</p>
TicketDenis-de-BernardyFri, 10 Jul 2009 21:40:14 GMThttps://core.trac.wordpress.org/ticket/10360#comment:10
https://core.trac.wordpress.org/ticket/10360#comment:10
<p>
@vladimir: There was some discussion related to what should end up in $_REQUEST in the related ticket.
</p>
<p>
FWIW, the whole point of the ticket was to remove $_COOKIES from $_REQUEST for security reasons, without introducing a wp_gpc() function that would end up adding needless overhead. If phpBB uses $_REQUEST where $_COOKIES should be used, they took a very questionable option.
</p>
<p>
It was decided to ignore the gpc order and to stick to $_GET and $_POST, because there's no straightforward way to know whether $_SERVER and $_ENV are included and in which order. (There are many php ini settings that serve the same purpose.)
</p>
Ticketvladimir_kolesnikovFri, 10 Jul 2009 21:46:28 GMThttps://core.trac.wordpress.org/ticket/10360#comment:11
https://core.trac.wordpress.org/ticket/10360#comment:11
<p>
Thanks for the explanation.
</p>
<p>
Unless I am missing something, according to <a class="ext-link" href="http://us.php.net/manual/en/reserved.variables.request.php"><span class="icon">​</span>http://us.php.net/manual/en/reserved.variables.request.php</a> $_REQUEST is always $_GET + $_POST + $_COOKIE and the order depends upon variables_order setting. $_SERVER and $_ENV are not merged into $_REQUEST.
</p>
TicketDenis-de-BernardyFri, 10 Jul 2009 21:52:36 GMThttps://core.trac.wordpress.org/ticket/10360#comment:12
https://core.trac.wordpress.org/ticket/10360#comment:12
<p>
yeah, but see also the changelog on the same page (it used to have $_FILES), and:
</p>
<ul><li><a class="ext-link" href="http://us.php.net/manual/en/ini.core.php#ini.request-order"><span class="icon">​</span>http://us.php.net/manual/en/ini.core.php#ini.request-order</a>
</li></ul><ul><li><a class="ext-link" href="http://us.php.net/manual/en/ini.core.php#ini.variables-order"><span class="icon">​</span>http://us.php.net/manual/en/ini.core.php#ini.variables-order</a> and its note on S meaning ES
</li></ul><ul><li>the discussions on <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/8814" title="defect (bug): Bad use of $_REQUEST variable in wordpress (closed: fixed)">#8814</a>
</li></ul>
Ticketvladimir_kolesnikovFri, 10 Jul 2009 22:47:12 GMThttps://core.trac.wordpress.org/ticket/10360#comment:13
https://core.trac.wordpress.org/ticket/10360#comment:13
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/10360#comment:12" title="Comment 12 for Ticket #10360">Denis-de-Bernardy</a>:
</p>
<blockquote class="citation">
<ul><li><a class="ext-link" href="http://us.php.net/manual/en/ini.core.php#ini.variables-order"><span class="icon">​</span>http://us.php.net/manual/en/ini.core.php#ini.variables-order</a> and its note on S meaning ES
</li></ul></blockquote>
<p>
This only affects $_SERVER - that is, $_SERVER will always have $_ENV array merged in.
</p>
<p>
See <a class="ext-link" href="http://blog.sjinks.org.ua/p.php"><span class="icon">​</span>http://blog.sjinks.org.ua/p.php</a> (screenshot: <a class="ext-link" href="https://url.odesk.com/bw6ig"><span class="icon">​</span>https://url.odesk.com/bw6ig</a>) - the server has variables_order set to EGPCS but $_REQUEST still contains only $_GET + $_POST + $_COOKIE.
</p>
<p>
variables_order affects which superglobals are created, the order how G/P/C are put into _REQUEST and the order in which E/G/P/C/S get imported into the global namespace if register_global is on.
</p>
<blockquote class="citation">
<p>
<a class="ext-link" href="http://us.php.net/manual/en/ini.core.php#ini.request-order"><span class="icon">​</span>http://us.php.net/manual/en/ini.core.php#ini.request-order</a>
</p>
</blockquote>
<p>
"This directive describes the order in which PHP registers GET, POST and Cookie variables into the _REQUEST array" - the manual does not mention any other superglobals.
</p>
<p>
Also <a class="ext-link" href="http://us.php.net/manual/en/reserved.variables.request.php"><span class="icon">​</span>http://us.php.net/manual/en/reserved.variables.request.php</a>: "When running on the command line, this will not include the argv and argc entries; these are present in the $_SERVER array." - this explicitly states that $_SERVER is not a part of $_REQUEST.
</p>
<p>
Finally, if you take a look at main/php_variables.c in the PHP source (you need the function named php_auto_globals_create_request), you'll see it never uses anything else but G/P/C (screenshot: <a class="ext-link" href="https://url.odesk.com/1eo0y"><span class="icon">​</span>https://url.odesk.com/1eo0y</a>).
</p>
TicketDenis-de-BernardyFri, 10 Jul 2009 22:50:01 GMThttps://core.trac.wordpress.org/ticket/10360#comment:14
https://core.trac.wordpress.org/ticket/10360#comment:14
<p>
But that applies to recent php versions, no? I couldn't care less if SERVER and ENV get in there, personally, as long as cookies aren't included. ;-)
</p>
Ticketvladimir_kolesnikovFri, 10 Jul 2009 22:58:34 GMThttps://core.trac.wordpress.org/ticket/10360#comment:15
https://core.trac.wordpress.org/ticket/10360#comment:15
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/10360#comment:14" title="Comment 14 for Ticket #10360">Denis-de-Bernardy</a>:
</p>
<blockquote class="citation">
<p>
But that applies to recent php versions, no?
</p>
</blockquote>
<p>
4.3.0 behaves the same way but the code is located in main/main.c
</p>
TicketDenis-de-BernardyFri, 10 Jul 2009 23:16:02 GMThttps://core.trac.wordpress.org/ticket/10360#comment:16
https://core.trac.wordpress.org/ticket/10360#comment:16
<p>
oh, ok. so then, merging $_GET and $_POST seems like the perfectly valid shortcut in retrospect. Remains to slash it properly.
</p>
TickethakreSat, 11 Jul 2009 09:40:22 GMThttps://core.trac.wordpress.org/ticket/10360#comment:17
https://core.trac.wordpress.org/ticket/10360#comment:17
<p>
Using $_REQUEST should just considered bad practice. Whatever is merged in there. Infact you can't properly determine without checking the php configuration and with wordpress even the core code. For any developer I would advise to not use it. Anyway that is just a sidenote.
</p>
<p>
Since parts of the wordpress code (still) depend on $_REQUEST it should contain at least the same values like $_POST and $_GET (like Denis points out). If $_POST and $_GET is slashed in another way then $_REQUEST is (as this ticket suggests), there is need to have it the same way.
</p>
<p>
Merging should be placed after salshing $_POST and $_GET.
</p>
<p>
Additionally an object could be instatiated that abstracts and contains the request data as submitted. This object can then be used to give access to untainted values as well to give access to post, get, files, cookies, (a configured) request and whatever is needed or usefull.
</p>
<p>
So is there any piece of documentation available wether or not $_REQUEST should contained untainted or slashed data? Even though it does differ from $_POST / $_GET it might be the intended behaviour. For the case it should be the same I can provide a patch.
</p>
Ticketdd32Sat, 11 Jul 2009 09:45:47 GMTattachment sethttps://core.trac.wordpress.org/ticket/10360
https://core.trac.wordpress.org/ticket/10360
<ul>
<li><strong>attachment</strong>
set to <em>10360.diff</em>
</li>
</ul>
Ticketdd32Sat, 11 Jul 2009 09:46:59 GMTkeywords, version changedhttps://core.trac.wordpress.org/ticket/10360#comment:18
https://core.trac.wordpress.org/ticket/10360#comment:18
<ul>
<li><strong>keywords</strong>
<em>has-patch</em> added; <em>needs-patch</em> <em>dev-feedback</em> removed
</li>
<li><strong>version</strong>
changed from <em>2.9</em> to <em>2.8</em>
</li>
</ul>
<blockquote class="citation">
<p>
attachment 10360.diff added
</p>
</blockquote>
<ul><li>Moves $_REQUEST merge of GET/POST to after slashing has been taken care of.
</li></ul>
TicketDenis-de-BernardySat, 11 Jul 2009 09:53:17 GMTattachment sethttps://core.trac.wordpress.org/ticket/10360
https://core.trac.wordpress.org/ticket/10360
<ul>
<li><strong>attachment</strong>
set to <em>10360.2.diff</em>
</li>
</ul>
<p>
alternative approach: slash $_REQUEST
</p>
TicketDenis-de-BernardySat, 11 Jul 2009 09:55:09 GMThttps://core.trac.wordpress.org/ticket/10360#comment:19
https://core.trac.wordpress.org/ticket/10360#comment:19
<p>
added a patch that slashes $_REQUEST instead, in case we want to keep $_REQUEST with the same data all along.
</p>
TickethakreSat, 11 Jul 2009 10:03:24 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/10360#comment:20
https://core.trac.wordpress.org/ticket/10360#comment:20
<ul>
<li><strong>keywords</strong>
<em>dev-feedback</em> added; <em>has-patch</em> removed
</li>
</ul>
<p>
Just reviewed the code. According to inline documentation
</p>
<pre class="wiki">// Force REQUEST to be GET + POST. If SERVER, COOKIE, or ENV are needed, use those superglobals directly.
</pre><p>
, $_REQUEST is to be expected forced GET + POST. Both are mostly untainted that time so therefore I strongly speak to wontfix or invalid. There is no need to expect $_REQUEST to be slashed.
</p>
<p>
I do not see any motivation to write a patch then.
</p>
TickethakreSat, 11 Jul 2009 10:04:44 GMThttps://core.trac.wordpress.org/ticket/10360#comment:21
https://core.trac.wordpress.org/ticket/10360#comment:21
<p>
Just to remind: If it's the point to not change the way to slash request variables, then this is true for $_REQUEST as well. This Ticket is invalid then.
</p>
Ticketdd32Sat, 11 Jul 2009 10:07:13 GMThttps://core.trac.wordpress.org/ticket/10360#comment:22
https://core.trac.wordpress.org/ticket/10360#comment:22
<blockquote class="citation">
<p>
added a patch that slashes $_REQUEST instead
</p>
</blockquote>
<p>
I didnt see the point in slashing the data twice, and before that block is hit, you cant guarantee what condition the data is in those variables. AFAIK nothing(mission critical) uses any of the request-related globals before then anyway
</p>
<blockquote class="citation">
<p>
Just to remind: If it's the point to not change the way to slash request variables, then this is true for $_REQUEST as well. This Ticket is invalid then.
</p>
</blockquote>
<p>
Not sure i can follow that english..
</p>
TicketDenis-de-BernardySat, 11 Jul 2009 10:09:38 GMThttps://core.trac.wordpress.org/ticket/10360#comment:23
https://core.trac.wordpress.org/ticket/10360#comment:23
<p>
hehe, as I wrote, it's "in case we want to keep $_REQUEST with the same data all along" (which I don't think we do either).
</p>
<p>
@hakre: ticket is not invalid, and not slashing $_REQUEST can introduce potential security issues if a plugin uses it expecting it's always slashed.
</p>
Ticketdd32Sat, 11 Jul 2009 10:12:33 GMThttps://core.trac.wordpress.org/ticket/10360#comment:24
https://core.trac.wordpress.org/ticket/10360#comment:24
<p>
Sorry missed your first comment
</p>
<blockquote class="citation">
<p>
, $_REQUEST is to be expected forced GET + POST. Both are mostly untainted that time so therefore I strongly speak to wontfix or invalid. There is no need to expect $_REQUEST to be slashed.
</p>
</blockquote>
<p>
Except like what i originally said: (now paraphrased)
</p>
<p>
WordPress will force $_GET/$_POST to be slashed REGARDLESS OF SERVER SETUP, $_REQUEST doesnt gain the same treatment.
</p>
<p>
the comment in the code is just to force $_REQUEST to $_GET/$_POST (ie. To exclude $_SERVER and $_COOKIE)
</p>
<p>
The end result on a Server where Magic quotes are disabled is as such:
</p>
<pre class="wiki">POST Data = "O'Niel";
$_POST = "O\'Niel";
$_REQUEST = "O'Niel";
</pre>
Ticketvladimir_kolesnikovSat, 11 Jul 2009 10:19:46 GMThttps://core.trac.wordpress.org/ticket/10360#comment:25
https://core.trac.wordpress.org/ticket/10360#comment:25
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/10360#comment:23" title="Comment 23 for Ticket #10360">Denis-de-Bernardy</a>:
</p>
<blockquote class="citation">
<p>
@hakre: ticket is not invalid, and not slashing $_REQUEST can introduce potential security issues if a plugin uses it expecting it's always slashed.
</p>
</blockquote>
<p>
On the other hand, this might break the plugins that relied upon the old behavior (for example, if I know that $_REQUEST is unslashed, I can pass its variables (without applying stripslashes()) to $wpdb-&gt;insert()/$wpdb-&gt;update()).
</p>
<p>
I agree that relying upon $_REQUEST is a bad practice that should be avoided unless you know what you do; what I dislike is that hacking with $_REQUEST breaks 3rd party software.
</p>
TickethakreSat, 11 Jul 2009 18:37:23 GMThttps://core.trac.wordpress.org/ticket/10360#comment:26
https://core.trac.wordpress.org/ticket/10360#comment:26
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/10360#comment:22" title="Comment 22 for Ticket #10360">dd32</a>:
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
Just to remind: If it's the point to not change the way to slash request variables, then this is true for $_REQUEST as well. This Ticket is invalid then.
</p>
</blockquote>
<p>
Not sure i can follow that english..
</p>
</blockquote>
<p>
In diverse discussion it has been stated many, many times that there will be no change in the way WordPress slashes the data. This is because of the status quo. So this ticket's report must be bogus as well. Because changing the well accepted behavior of $_REQUEST will change the WordPress behavior of how request variables are slashed.
</p>
<p>
<strong>As it has been clearly said that the way WordPress slahes request related data has not to be touched</strong> this ticket is plain invalid.
</p>
<p>
I hope I can make the point more clear now.
</p>
TickethakreSat, 11 Jul 2009 18:41:40 GMThttps://core.trac.wordpress.org/ticket/10360#comment:27
https://core.trac.wordpress.org/ticket/10360#comment:27
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/10360#comment:23" title="Comment 23 for Ticket #10360">Denis-de-Bernardy</a>:
</p>
<blockquote class="citation">
<p>
@hakre: ticket is not invalid, and not slashing $_REQUEST can introduce potential security issues if a plugin uses it expecting it's always slashed.
</p>
</blockquote>
<p>
The way WordPress handles the request data per se introduces a lot of potential security isseus. So this is ticket is not the right place to pick that topic. Especially having $_REQUEST untainted is a kind of better practice as the pseudo-security with $_POST and $_GET.
</p>
Ticketdd32Fri, 24 Jul 2009 23:27:39 GMTkeywords changedhttps://core.trac.wordpress.org/ticket/10360#comment:28
https://core.trac.wordpress.org/ticket/10360#comment:28
<ul>
<li><strong>keywords</strong>
<em>has-patch</em> <em>commit</em> added; <em>dev-feedback</em> removed
</li>
</ul>
<p>
We all agree that relying upon slashed data in superglobals is bad. Theres no question about it.
</p>
<p>
This is about CONSISTENCY.
</p>
<p>
<tt>$_POST['something']</tt> should be able to be replaced by <tt>$_REQUEST['something']</tt> and act EXACTLY THE SAME. This is not currently happening due to WordPress's Slashing of data in <tt>$_GET/$_POST</tt> but NOT in $_REQUEST (Which may be slashed if the server has it enabled, or not slashed otherwise..)
</p>
<p>
The slashing of data is NOT for this ticket, and another ticket has recently been closed around it.
</p>
TickethakreSun, 26 Jul 2009 12:00:27 GMThttps://core.trac.wordpress.org/ticket/10360#comment:29
https://core.trac.wordpress.org/ticket/10360#comment:29
<p>
+1 for removing slashes from _POST and _GET sothat - as dd32 makes bold - _POST and _GET can be replaced anytime with _REQUEST. Plus the point that "we all agree that relying upon slashed data in superglobals is bad." (is the wordpress maintainer part of that "we" or not?)
</p>
<p>
The currrent patch does not reflect that, it just merges (slashes) _POST &amp; _GET into _REQUEST and not the other way round (dd32 wrote about replacing _POST resp. _GET with _REQUEST and not the other way round).
</p>
<p>
So I see no has-patch nor commit readyness.
</p>
<p>
How can we get a valid statement from the maintainer on this issue?
</p>
TickethakreSun, 26 Jul 2009 12:01:59 GMThttps://core.trac.wordpress.org/ticket/10360#comment:30
https://core.trac.wordpress.org/ticket/10360#comment:30
<p>
Replying to <a class="closed" href="https://core.trac.wordpress.org/ticket/10360#comment:28" title="Comment 28 for Ticket #10360">dd32</a>:
</p>
<blockquote class="citation">
<p>
The slashing of data is NOT for this ticket, and another ticket has recently been closed around it.
</p>
</blockquote>
<p>
Please reference that ticket. Thanks.
</p>
Ticketdd32Sun, 26 Jul 2009 12:08:39 GMThttps://core.trac.wordpress.org/ticket/10360#comment:31
https://core.trac.wordpress.org/ticket/10360#comment:31
<blockquote class="citation">
<p>
+1 for removing slashes from _POST and _GET sothat - as dd32 makes bold
</p>
</blockquote>
<p>
My comment was never intended to be taken that way.
</p>
<p>
I intended that the use of $_POST inside wordpress should be able to be replaced with $_REQUEST at any stage and operate the same. This infers that the slashes in REQUEST should be the same as POST. I am not referring to some non-WP application. <strong>Simple fact is, WordPress uses/expects POST/GET data to be slashed, Even though internally data is used unslashed in recent versions. $_REQUEST is NOT slashed, and therefor, cannot be used interchangably</strong>
</p>
<blockquote class="citation">
<p>
Please reference that ticket. Thanks.
</p>
</blockquote>
<p>
Search for it. I'm not your personal search engine.
</p>
TickethakreSun, 26 Jul 2009 18:18:00 GMThttps://core.trac.wordpress.org/ticket/10360#comment:32
https://core.trac.wordpress.org/ticket/10360#comment:32
<p>
("'Quote' on Quote") Simple fact is, WordPress uses/expects the $_REQUEST data not to be slashed. If you say A for _POST and _GET, then you must say B for_REQUEST. If you argue to keep up with the status quo, then this is an argument against changing current $_REQUEST data.
</p>
<p>
If you decide to change the current slashing of the superglobals containing request data, then I suggest to stop slashing them to improve the dataflow instead of repeating wrong decisions of the past.
</p>
<p>
Additionally I have only asked that you link to the other ticket you used as argument. I know that there are a lot of tickets that are about slashing or not slashing data so I can not exactly follow your point until you link that certain ticket you meant. That's all. I know how to deal with the trac search, so please do not feel offended by me asking. I thought you have it in your browsers history or similar.
</p>
Ticketdd32Sun, 26 Jul 2009 22:10:06 GMThttps://core.trac.wordpress.org/ticket/10360#comment:33
https://core.trac.wordpress.org/ticket/10360#comment:33
<p>
see <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/10452" title="defect (bug): Wordpress pollutes POST data (closed: wontfix)">#10452</a>
</p>
<blockquote class="citation">
<p>
If you decide to change the current slashing of the superglobals containing request data, then I suggest to stop slashing them to improve the dataflow instead of repeating wrong decisions of the past.
</p>
</blockquote>
<p>
I would agree, Except that since it was decided in <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/10452" title="defect (bug): Wordpress pollutes POST data (closed: wontfix)">#10452</a> to not removing slashing (Whch is where the 'remove slashing' discussion belongs) then the request-related vars should follow a similar curve to each other.
</p>
<p>
I'm going to bring this up in this weeks Developer discussion on IRC.
</p>
TickethakreMon, 27 Jul 2009 00:41:17 GMThttps://core.trac.wordpress.org/ticket/10360#comment:34
https://core.trac.wordpress.org/ticket/10360#comment:34
<p>
+1 that really is a good idea. I would love to see a maintainers statement in/after that discussion. I know that this is not easy to decide but I think it should be given a clear statement that leads into the right direction for the future.
</p>
<p>
Next to what I (personally) would prefer it was for me in WP devrlopment to stick with the current status quo (wether or not it's a personal preference). I'm personally very open minded to have a more well defined data flow (that means to not slash the data as this is consent in the PHP community _mostly_ but not overall (WordPress is one exception, another one might be phplist [not that shure] but then my knowledge ends).
</p>
TicketmarkjaquithFri, 31 Jul 2009 22:13:25 GMTowner, status changedhttps://core.trac.wordpress.org/ticket/10360#comment:35
https://core.trac.wordpress.org/ticket/10360#comment:35
<ul>
<li><strong>owner</strong>
changed from <em>ryan</em> to <em>markjaquith</em>
</li>
<li><strong>status</strong>
changed from <em>new</em> to <em>accepted</em>
</li>
</ul>
<p>
I regret that "always slashed" was chosen for <tt>$_GET</tt> and <tt>$_POST</tt>, but that ship has sailed. If we want to change that, it's going to be a long journey, because there is a very real possibility that such a change will introduce security issues in plugins. But that is a separate topic.
</p>
<p>
I agree with dd32 that this is about consistency. Honestly, <strong>it was news to me</strong> that <tt>$_REQUEST</tt> is not slashed (not that I'm in the habit of trusting user data!) I regard <tt>$_REQUEST</tt> as <tt>$_GET</tt> + <tt>$_POST</tt>, and both <tt>$_GET</tt> and <tt>$_POST</tt> are always slashed—so why wouldn't <tt>$_REQUEST</tt> always be slashed? There is the possibility that changing this will break a few plugins for some setups, <strong>but those plugins were already broken</strong> because on other server setups <tt>$_REQUEST</tt> <strong>will</strong> be slashed.
</p>
<p>
Simply put, as it is now, <tt>$_REQUEST</tt> is unpredictable, and any use of it that would be affected by "slashable" data <strong>is currently unstable</strong>. dd32's patch fixes this, by making it consistent (with itself) and consistend with <tt>$_GET</tt> and <tt>$_POST</tt>, as well as fixes it in a way that won't introduce SQL injection vulnerabilities.
</p>
TicketmarkjaquithFri, 31 Jul 2009 22:22:58 GMTstatus changed; resolution sethttps://core.trac.wordpress.org/ticket/10360#comment:36
https://core.trac.wordpress.org/ticket/10360#comment:36
<ul>
<li><strong>status</strong>
changed from <em>accepted</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
</ul>
<p>
(In <a class="changeset" href="https://core.trac.wordpress.org/changeset/11760" title="Be consistent about slashing _REQUEST superglobal. props dd32. fixes ...">[11760]</a>) Be consistent about slashing _REQUEST superglobal. props dd32. fixes <a class="closed ticket" href="https://core.trac.wordpress.org/ticket/10360" title="defect (bug): $_REQUEST's slashes may differ from $_GET/$_POST (closed: fixed)">#10360</a>
</p>
TickethakreSun, 16 Aug 2009 08:34:14 GMThttps://core.trac.wordpress.org/ticket/10360#comment:37
https://core.trac.wordpress.org/ticket/10360#comment:37
<p>
Then so shall it be.
</p>
Ticket