[PHP-DEV] Providing improved functionality for escaping html (and other) output.
It's important to escape output according to context. PHP provides
functions such as htmlspecialchars() to escape output when the context
is HTML. However, one often desires to allow some subset of HTML
through without escaping (e.g., , , etc.)
Functions such as strip_tags() do allow whitelisting, but their usage
poses security risks due to lingering attributes (e.g., strip_tags('click me', ''.)
One can develop a more robust mechanism in userland that first escapes
input using htmlspecialchars() and then unescapes whitelisted
sequences. Because of the variance in html tags due to potential
attributes (e.g., optionally including various classes, img src
attributes, etc), offering the ability to optionally specify a
whitelist sequence through use of a regex could also offer significant
benefits (e.g., any string sequence starting and ending with '/' will
be handled as a regex.) However, the common nature of this need,
coupled with the performance benefits of implementing this internally
prompts my interest in two options.
- Add a fifth parameter to htmlspecialchars() that takes an array of
whitelisted sequences. Even though this seems like a terribly long
function to call, one could easily wrap the call in a facade function.
- Add a new function called str_escape(), but this introduces
potential BC issues.
There are of course other options (e.g., integrate this as an
additional filter, etc.)
I've built an extension that, while focused on an old web framework of
mine, contains a function that can serve as a proof-of-concept that
implements the functionality I've outlined above (see
nephtali_str_escape_html):
https://github.com/AdamJonR/nephtali-php-ext/blob/master/nephtali.c
I've tossed out the idea on this list before, but it was only
tangentially related to the discussion at the time. At this point, I'd
really like to focus on this idea directly to see what approach might
seem wisest (including doing nothing, if the frequency of use does not
justify bringing the functionality into the core.)
Thoughts?
Adam
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
On 1/4/2013 4:29 PM, Stas Malyshev wrote: Hi! This shouldn't be an issue because it is not possible to set the property without going through the setter, which would be a type hinted accessor function. It is possible, if this property's guard is set. Since guard works for all code called from inside the setter, if setter is doing something not trivial (meaning, calls any functions, explicitly or implicitly) it is possible to set the property directly. Since the value you are getting is defined by the getter, there are no guarantees there too. So effectively, unless both getter and setter are implicit, this does not give you anything compared to the typed setter. I think I was referring to the possibility I mentioned in another email about a second call to a getter which was already guarded would return NULL and likewise a second call to a setter which was already being guarded would do whatever __set() does...? Ignored? -- -Clint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Agreed. Some people may actually be using $parent as a variable name, not difficult to imagine. So far parent->foo seems to be the answer. -Clint On 1/4/2013 4:23 PM, Stas Malyshev wrote: Hi! One other possible alternative would be to treat parent "like a variable..." $parent->foo That would be a big BC problem and also require serious changes to handle it (look how $this is implemented - it's not regular variable at all). So $parent is probably a non-starter. -- -Clint
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
On Sat, Jan 5, 2013 at 12:31 AM, Steve Clay wrote:
> Would the following two be exactly functionally equivalent?
>
> public Foo $foo;
>
> public $foo {
> get;
> set(Foo $value) { $this->foo = $value; }
> }
>
> We should also consider how an author would allow type-hinted properties
> to accept NULL as a new value, in both proposals.
>
I think that's a very interesting question, thanks for bringing it up. I
think a good approach here would be the same one used for function argument
typehints, i.e. allow NULL when NULL is specified as the default value. So
`public DateTime $date;` would not allow an explicit NULL assignment,
whereas `public DateTime $date = NULL;` would.
Nikita
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
On Fri, Jan 4, 2013 at 4:34 PM, Levi Morrison wrote:
>>We should also consider how an author would allow type-hinted properties to
>>accept NULL as a new value, in both proposals.
>
> public $foo {
> get;
> set(Foo $value = NULL) { $this->foo = $value; }
> }
>
> Would work for traditional type-hints.
I just realized that `unset` would actually have a use here. Rather
than setting something to `null` you would `unset` it.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
>We should also consider how an author would allow type-hinted properties to
>accept NULL as a new value, in both proposals.
public $foo {
get;
set(Foo $value = NULL) { $this->foo = $value; }
}
Would work for traditional type-hints.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
Would the following two be exactly functionally equivalent?
public Foo $foo;
public $foo {
get;
set(Foo $value) { $this->foo = $value; }
}
We should also consider how an author would allow type-hinted properties to
accept NULL as a new value, in both proposals.
Steve
--
http://www.mrclay.org/
On Jan 4, 2013, at 9:41 AM, Nikita Popov wrote:
> Hi internals!
>
> I already brought this up before, but I think the discussion at that time
> was not very constructive and largely off-topic, so I'm bringing it up
> again. To make sure everything is clear I wrote an RFC document:
>
> https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax
>
> This RFC proposes an alternative syntax for typehinting accessors, which
> will in particular also allow to typehint properties directly, even if no
> accessors are used (public DateTime $date).
>
> What are your opinions on this?
>
> Thanks,
> Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
Hi! > This shouldn't be an issue because it is not possible to set the > property without going through the setter, which would be a type hinted > accessor function. It is possible, if this property's guard is set. Since guard works for all code called from inside the setter, if setter is doing something not trivial (meaning, calls any functions, explicitly or implicitly) it is possible to set the property directly. Since the value you are getting is defined by the getter, there are no guarantees there too. So effectively, unless both getter and setter are implicit, this does not give you anything compared to the typed setter. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi! > One other possible alternative would be to treat parent "like a variable..." > > $parent->foo That would be a big BC problem and also require serious changes to handle it (look how $this is implemented - it's not regular variable at all). So $parent is probably a non-starter. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to get a PHP bug fixed?
On Fri, 4 Jan 2013, Paul Taulborg wrote: > I submitted a bugfix patch for this one: > https://bugs.php.net/bug.php?id=63615 on 2012-12-06 > and asked for feedback here, to make sure this was intended > functionality. I also have not heard back, and the bug is still > unassigned. It's not something that ever affected me personally, it > was a random bug that I saw and fixed while in the date/time section > of the core. I will have to double check whether this is intended or not. I'm slowly getting to look at datetime issues again, and will get to it at some point (soon). cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to get a PHP bug fixed?
Hi! > Hi, there is a bug(s) I'd like to be fixed and even a patch is available. > But there is still no reaction at all after 2 years. What else can I do to > get the bug(s) fixed? Pull request may speed things up, writing to internals might too :) > https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13 This patch seems to do only part of the work - it does not add the option to getTrace, it does not use DEBUG_BACKTRACE_* constants and it does not have tests. If you are willing to get it to completion and submit a pull request with complete fix, it can be integrated pretty quickly, > https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13 > This one was waiting for maintainer's input. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to get a PHP bug fixed?
Adding Derick to the loop On Jan 4, 2013 8:23 PM, "Paul Taulborg" wrote: > I submitted a bugfix patch for this one: > https://bugs.php.net/bug.php?id=63615 on 2012-12-06 > and asked for feedback here, to make sure this was intended > functionality. I also have not heard back, and the bug is still > unassigned. It's not something that ever affected me personally, it > was a random bug that I saw and fixed while in the date/time section > of the core. > > Thanks in advance :) > > On Fri, Jan 4, 2013 at 11:36 AM, Ferenc Kovacs wrote: > > On Fri, Jan 4, 2013 at 6:33 PM, Enumag wrote: > > > >> Hi, there is a bug(s) I'd like to be fixed and even a patch is > available. > >> But there is still no reaction at all after 2 years. What else can I do > to > >> get the bug(s) fixed? > >> > >> https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13 > >> https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13 > >> > > > > bringing that up here can help! :) > > > > -- > > Ferenc Kovács > > @Tyr43l - http://tyrael.hu > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] How to get a PHP bug fixed?
I submitted a bugfix patch for this one: https://bugs.php.net/bug.php?id=63615 on 2012-12-06 and asked for feedback here, to make sure this was intended functionality. I also have not heard back, and the bug is still unassigned. It's not something that ever affected me personally, it was a random bug that I saw and fixed while in the date/time section of the core. Thanks in advance :) On Fri, Jan 4, 2013 at 11:36 AM, Ferenc Kovacs wrote: > On Fri, Jan 4, 2013 at 6:33 PM, Enumag wrote: > >> Hi, there is a bug(s) I'd like to be fixed and even a patch is available. >> But there is still no reaction at all after 2 years. What else can I do to >> get the bug(s) fixed? >> >> https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13 >> https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13 >> > > bringing that up here can help! :) > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to get a PHP bug fixed?
On Fri, Jan 4, 2013 at 6:33 PM, Enumag wrote: > Hi, there is a bug(s) I'd like to be fixed and even a patch is available. > But there is still no reaction at all after 2 years. What else can I do to > get the bug(s) fixed? > > https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13 > https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13 > bringing that up here can help! :) -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] How to get a PHP bug fixed?
Hi, there is a bug(s) I'd like to be fixed and even a patch is available. But there is still no reaction at all after 2 years. What else can I do to get the bug(s) fixed? https://bugs.php.net/bug.php?id=45351 - patch available from 2010-06-13 https://bugs.php.net/bug.php?id=48724 - patch available from 2012-04-13
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi Clint, got it. Am 04.01.2013 um 16:28 schrieb Clint Priest : > Uhm.. brain fart. > > I was thinking $this->$foo was normal when I wrote this up, I would change my > last statement from the earlier email to any syntax which did not include a $. > > That being said then, I think I favor parent->foo the best. It’s not really a matter of syntax, but a matte of principle. We shouldn’t burden our users with another syntax to achieve the same thing. cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Uhm.. brain fart. I was thinking $this->$foo was normal when I wrote this up, I would change my last statement from the earlier email to any syntax which did not include a $. That being said then, I think I favor parent->foo the best. One other possible alternative would be to treat parent "like a variable..." $parent->foo On 1/4/2013 5:09 AM, Clint Priest wrote: Speaking of which, parent::foo ( with :: but no $) might work as well, almost *any* character change could work... parent:::$foo parent:$foo parent->$foo parent->foo parent.$foo parent.foo I favor having the $ in some solution though... -Clint On Jan 4, 2013, at 5:04 AM, Clint Priest wrote: Missed that bit... I think that would add two bits of inconsistency though... (Without the $) -Clint On Jan 4, 2013, at 1:18 AM, Stas Malyshev wrote: Hi! A recent suggestion from Stas is to use parent->$foo (note the use of -> rather than ::) I actually proposed parent->foo. parent->$foo implies the name of the variable is "$foo", not "foo" - just as in $this->$foo. Yes, I know it does not match parent::$foo - but I can't do much about it. In any case, better not to add another inconsistency to the list of existing ones. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- -Clint
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
This shouldn't be an issue because it is not possible to set the property without going through the setter, which would be a type hinted accessor function. Ergo, an attempt to set the value to an invalid value would cause a fatal error and thus the setter would not be able to then set it to the invalid value. On 1/4/2013 9:15 AM, Levi Morrison wrote: This proposal looks really good to me. It cuts out a lot of syntax and boilerplate for a commonly used case. However, there is one issue that I know somebody is going to raise: Argument: If you change the value of the property without using the setter then `get` could return something that has a type mismatch with the type-hint. If I understand the current RFC for properties correctly, the only place that a property can be directly written to without the accessor is inside of the `__setProperty` method. This almost nullifies the argument completely. The only other place for possible error would be assigning a value in the constructor that does not match the type-hint. However, because we adding a new syntax we *could* disallow assigning a value if it really was that problematic. I do not personally feel that would be necessary. I feel that this argument is not weighty enough to stop the proposal for this improved syntax. -- -Clint
Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
This proposal looks really good to me. It cuts out a lot of syntax and boilerplate for a commonly used case. However, there is one issue that I know somebody is going to raise: Argument: If you change the value of the property without using the setter then `get` could return something that has a type mismatch with the type-hint. If I understand the current RFC for properties correctly, the only place that a property can be directly written to without the accessor is inside of the `__setProperty` method. This almost nullifies the argument completely. The only other place for possible error would be assigning a value in the constructor that does not match the type-hint. However, because we adding a new syntax we *could* disallow assigning a value if it really was that problematic. I do not personally feel that would be necessary. I feel that this argument is not weighty enough to stop the proposal for this improved syntax. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #63699 Poor date()/etc performance [PATCH]
Are there any updates on this? I submitted this patch a month ago that is a significant performance increase for some commonly used date/time functions: https://bugs.php.net/bug.php?id=63699 Can anyone provide feedback on this, and any possible reasons why this seems to be shelved? Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Alternative typehinting syntax for accessors
Hi internals! I already brought this up before, but I think the discussion at that time was not very constructive and largely off-topic, so I'm bringing it up again. To make sure everything is clear I wrote an RFC document: https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax This RFC proposes an alternative syntax for typehinting accessors, which will in particular also allow to typehint properties directly, even if no accessors are used (public DateTime $date). What are your opinions on this? Thanks, Nikita
Re: [PHP-DEV] Bug #23815: Added extra ImageCopyMergeAlpha function
No need to create another function for that. I will do it once I am back at work next week. On Jan 3, 2013 12:33 PM, "Lars Strojny" wrote: > No objection from my POV. Going to merge it in around a week, if no one > objects. > > Am 02.01.2013 um 10:35 schrieb matt clegg : > > > I have added ImageCopyMergeAlpha as an extra function to resolve bug > 23815. > > > > I have created a pull request on github > > https://github.com/php/php-src/pull/211 > > > > Can this be merged into 5.5? And, what do I need to do? > > > > -- > > > > > > Matt Clegg > > > > --http://mattclegg.com/ > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Hi Clint,
Am 04.01.2013 um 04:13 schrieb Clint Priest :
[...]
> 1) It forces the user to access the parent property accessor in a different
> way than is used everywhere else
Isn’t that the same as parent->$foo? Please let’s not introduce a special
syntax for something that can be done properly. I would either go with variant
2 ("Rewrite the way static property references work"). If that takes too long
and we feel that a version without parent access is sufficient, we should
disallow parent access for version 1 of property accessors.
cu,
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Speaking of which, parent::foo ( with :: but no $) might work as well, almost *any* character change could work... parent:::$foo parent:$foo parent->$foo parent->foo parent.$foo parent.foo I favor having the $ in some solution though... -Clint On Jan 4, 2013, at 5:04 AM, Clint Priest wrote: > Missed that bit... I think that would add two bits of inconsistency > though... (Without the $) > > -Clint > > On Jan 4, 2013, at 1:18 AM, Stas Malyshev wrote: > >> Hi! >> >>> A recent suggestion from Stas is to use parent->$foo (note the use of -> >>> rather than ::) >> >> I actually proposed parent->foo. parent->$foo implies the name of the >> variable is "$foo", not "foo" - just as in $this->$foo. Yes, I know it >> does not match parent::$foo - but I can't do much about it. In any case, >> better not to add another inconsistency to the list of existing ones. >> >> -- >> Stanislav Malyshev, Software Architect >> SugarCRM: http://www.sugarcrm.com/ >> (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-RFC] Property Accessors 1.2 : parent::$foo Issue
Missed that bit... I think that would add two bits of inconsistency though... (Without the $) -Clint On Jan 4, 2013, at 1:18 AM, Stas Malyshev wrote: > Hi! > >> A recent suggestion from Stas is to use parent->$foo (note the use of -> >> rather than ::) > > I actually proposed parent->foo. parent->$foo implies the name of the > variable is "$foo", not "foo" - just as in $this->$foo. Yes, I know it > does not match parent::$foo - but I can't do much about it. In any case, > better not to add another inconsistency to the list of existing ones. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
