php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #76215 7.3: strip_tags deprecation of "allowed_tags"
Submitted: 2018-04-13 07:33 UTC Modified: 2018-04-13 08:46 UTC
From: spam2 at rhsoft dot net Assigned:
Status: Not a bug Package: Scripting Engine problem
PHP Version: Next Minor Version OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: spam2 at rhsoft dot net
New email:
PHP Version: OS:

 

 [2018-04-13 07:33 UTC] 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?

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-04-13 07:34 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2018-04-13 07:34 UTC] requinix@php.net 
Take this to the internals list.
 [2018-04-13 07:38 UTC] 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:39 UTC] 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 08:46 UTC] cmb@php.net 
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.
 [2018-04-13 08:59 UTC] spam2 at rhsoft dot net 
completly irrelevant - as always it depends on the usecase - in the usecase i described the user *anyways* does a optin by click the icon "cleanup" and now you need to explain me how "not cleanup everything" is worser than don't have the option at all

this is *not* a security relevant usecase at all, it's about get the biggest mess cleaned combined with what WYSIWYG editors do with Javascript - none of both is working perfect - but both combined is better than one alone

AGAIN: there is no point removing a fteaure because it could be used wrong - that applies to nearly any feature of a programming language
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 25 20:01:45 2024 UTC