Bug #76215 [Nab]: 7.3: strip_tags deprecation of "allowed_tags"

From: Date: Fri, 13 Apr 2018 08:46:55 +0000
Subject: Bug #76215 [Nab]: 7.3: strip_tags deprecation of "allowed_tags"
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-214727@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76215&edit=1 ID: 76215 Updated by: cmb@php.net Reported by: spam2 at rhsoft dot net Summary: 7.3: strip_tags deprecation of "allowed_tags" Status: Not a bug Type: Bug Package: Scripting Engine problem PHP Version: Next Minor Version Block user comment: N Private report: N New Comment: The main issue with the $allowable_tags parameter is that it retains the complete tag including all the attributes, even event handler attributes, see <https://3v4l.org/aRXQM>. This makes it rarely useful, if ever. Previous Comments: ------------------------------------------------------------------------ [2018-04-13 07:39:47] spam2 at rhsoft dot net so again: what is the improvement to take away existing funtionality because it could be used in stupid ways? that would affect the whole language too when using remote input in unsecure ways ------------------------------------------------------------------------ [2018-04-13 07:38:11] spam2 at rhsoft dot net you are a funny guy when you don't want me to post after i had enough of Tony Marstons "argumentation" and calling names on different topics ------------------------------------------------------------------------ [2018-04-13 07:34:58] requinix@php.net Take this to the internals list. ------------------------------------------------------------------------ [2018-04-13 07:33:40] spam2 at rhsoft dot net Description: ------------ https://wiki.php.net/rfc/deprecations_php_7_3 strip_tags() From some preliminary feedback: We might want to only deprecate the insecure allowed_tags parameter, but keep the ?strip all tags? functionality. This function appears to be useful as a relatively simple way of reusing code that outputs HTML in a different context (CLI output, text messages, etc.) what the hell do you gain with that? how is a param nobody is forced to use unsecure? i have a simple usecase which is *not* unsecure and i don't see any gain in break that: working in a WYSIWG-editor, cleanup pasted content and have a few checkboxes which tags should survive * headlines * paragraphs * <ul>, <ol>, <li> * tables default is strip everything in fact that works way better than all the existing javascript crap and in PHP it's a one-liner with a simple from-post and replace the WYSIWG-content where you could write any html code anyways in source-mode so again: what do you gain with remove functionality? ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=76215&edit=1

« previous php.bugs (#214727) next »