Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126297
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 05 Feb 2025 14:25:58 +0100
To: internals@lists.php.net
Message-ID: <b542f990-4055-477d-a66e-e00f520fae6b@app.fastmail.com>
In-Reply-To: <cbe7b1ea-4d23-4b7c-9dd9-f400ca7c5d11@gmx.de>
References: <cbe7b1ea-4d23-4b7c-9dd9-f400ca7c5d11@gmx.de>
Subject: Re: [PHP-DEV] Deprecate filter_input() or not?
Content-Type: multipart/alternative;
 boundary=16f3d363a300445dbee2934c0ee7d98d
From: rob@bottled.codes ("Rob Landers")

--16f3d363a300445dbee2934c0ee7d98d
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Wed, Feb 5, 2025, at 14:13, Christoph M. Becker wrote:
> Hi all!
>=20
> There is some discussion on a recent bug report[1] about filter_input()
> and related functionality.  The bug report had been closed, because th=
is
> functionality has already been added to the general deprecation RFC for
> PHP 8.5[2].  Then the OP raised a point regarding the usefulness of
> filter_input() to get at the original input, to avoid working with
> possibly modified superglobals.
>=20
> In my opinion, this topic should be discussed here, and not in a bug
> report.  So, has anybody thoughts about the filter_input() deprecation?
>=20
> [1] <https://github.com/php/php-src/issues/17543>
> [2]
> <https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_filter_input_=
filter_input_array_and_filter_has_var>
>=20
> Christoph
>=20

Hey Christoph,

I don=E2=80=99t know why they are focusing on WordPress specifically, bu=
t this function is vital for any software that runs untrusted code (plug=
ins, anything exec=E2=80=99d from /tmp =E2=80=94 ie, templates, compiled=
 containers, etc). Gina suggests using psr7 which suffers from the same =
problem in most frameworks, which allow setting a new request object or =
mutating it in some way.

I=E2=80=99m not sure it should be deprecated and I=E2=80=99d even argue =
not closing tickets just because they are in the mass-deprecation rfc th=
at hasn=E2=80=99t been voted on yet.=20

=E2=80=94 Rob
--16f3d363a300445dbee2934c0ee7d98d
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>=
<br></div><div>On Wed, Feb 5, 2025, at 14:13, Christoph M. Becker wrote:=
<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi all!<br=
></div><div><br></div><div>There is some discussion on a recent bug repo=
rt[1] about filter_input()<br></div><div>and related functionality.&nbsp=
; The bug report had been closed, because this<br></div><div>functionali=
ty has already been added to the general deprecation RFC for<br></div><d=
iv>PHP 8.5[2].&nbsp; Then the OP raised a point regarding the usefulness=
 of<br></div><div>filter_input() to get at the original input, to avoid =
working with<br></div><div>possibly modified superglobals.<br></div><div=
><br></div><div>In my opinion, this topic should be discussed here, and =
not in a bug<br></div><div>report.&nbsp; So, has anybody thoughts about =
the filter_input() deprecation?<br></div><div><br></div><div>[1] &lt;<a =
href=3D"https://github.com/php/php-src/issues/17543">https://github.com/=
php/php-src/issues/17543</a>&gt;<br></div><div>[2]<br></div><div>&lt;<a =
href=3D"https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_filter_i=
nput_filter_input_array_and_filter_has_var">https://wiki.php.net/rfc/dep=
recations_php_8_5#deprecate_filter_input_filter_input_array_and_filter_h=
as_var</a>&gt;<br></div><div><br></div><div>Christoph<br></div><div><br>=
</div></blockquote><div><br></div><div>Hey Christoph,<br></div><div><br>=
</div><div>I don=E2=80=99t know why they are focusing on WordPress speci=
fically, but this function is vital for any software that runs untrusted=
 code (plugins, anything exec=E2=80=99d from /tmp =E2=80=94 ie, template=
s, compiled containers, etc). Gina suggests using psr7 which suffers fro=
m the same problem in most frameworks, which allow setting a new request=
 object or mutating it in some way.<br></div><div><br></div><div>I=E2=80=
=99m not sure it should be deprecated and I=E2=80=99d even argue not clo=
sing tickets just because they are in the mass-deprecation rfc that hasn=
=E2=80=99t been voted on yet.&nbsp;</div><div><br></div><div id=3D"sig12=
1229152">=E2=80=94 Rob<br></div></body></html>
--16f3d363a300445dbee2934c0ee7d98d--