results of the PHP6 wishlists

19 years ago by Ron Korving — view source

unread

I was wondering; we've seen quite a few PHP6 wishlists passing by here. Is
there (and if not: should there be) a centralized spot where changes and new
features are logged, perhaps with a status saying whether somebody (and who)
is working on this, or if it's still being considered, or if it has been
rejected, etc...

Ron

19 years ago by Lukas Smith — view source

unread

Ron Korving wrote:

I was wondering; we've seen quite a few PHP6 wishlists passing by here. Is
there (and if not: should there be) a centralized spot where changes and new
features are logged, perhaps with a status saying whether somebody (and who)
is working on this, or if it's still being considered, or if it has been
rejected, etc...

I have created such a list with the help of a bunch of others. Its by no
means official, but fairly complete (yet its likely that most of the
points there will never make it):
http://oss.backendmedia.com/PhP60

regards,
Lukas

19 years ago by Roman Ivanov — view source

unread

wishlist> input filter extension (including some element of user control)

Will it be used instead of $_POST and $_GET? Honestly, I'm not so sure
it's a good idea to implement it like PECL extension does. Filtering
individual variables is, in my opinion, a wrong way to treat user input.

The way I do it on my sites:

Call dispatcher parses request variables to find out what to do. This
is done before request filtering.
System loads the filter that correspond to the target action.
If any of the request variables are invalid, than system does not
perform the action. Instead, it outputs message, stating which field was
filled incorrectly.
If all variables are correct, than system makes an array of "clean"
variable (i.e. only ones that were checked) and passes it to some function.

Simplified example:

$filter = array(
'name'=>'/^[\w\d]+$/',
'zip'=>'/^\d{5}$/',
'phone'=>'/^\d{7,16}$/',
);
try {
$input = filterInput($filter);
} catch (InvalidField $e) {
echo $e;
die();
}

Besides, is it really necessary to make input filtering a part of the
language? It's a very high-level feature, and implementation may vary
according to the needs of the developer. Plus, it's perfectly doable in
pure PHP. In fact, I would go as far as removing session handling
functions from the "core" language too. Such things would better fit a
framework or CMS.

My two cents, anyway.

19 years ago by Roman Ivanov — view source

unread

wishlist> input filter extension (including some element of user
wishlist> control)

Will it be used instead of $_POST and $_GET? Honestly, I'm not so sure
it's a good idea to implement it like PECL extension does. Filtering
individual variables is, in my opinion, a wrong way to treat user input.

The way I do it on my sites:

Call dispatcher parses request variables to find out what to do. This
is done before request filtering.
System loads the filter that correspond to the target action.
If any of the request variables are invalid, than system does not
perform the action. Instead, it outputs message, stating which field was
filled incorrectly.
If all variables are correct, than system makes an array of "clean"
variable (i.e. only ones that were checked) and passes it to some function.

Simplified example:

$filter = array(
'name'=>'/^[\w\d]+$/',
'zip'=>'/^\d{5}$/',
'phone'=>'/^\d{7,16}$/',
);
try {
$input = filterInput($filter);
} catch (InvalidField $e) {
echo $e;
die();
}

Besides, is it really necessary to make input filtering a part of the
language? It's a very high-level feature, and implementation may vary
according to the needs of the developer. Plus, it's perfectly doable in
pure PHP. In fact, I would go as far as removing session handling
functions from the "core" language too. Such things would better fit a
framework or CMS.

My two cents, anyway.

19 years ago by Antony Dovgal — view source

unread

wishlist> input filter extension (including some element of user
wishlist> control)

Will it be used instead of $_POST and $_GET?

An extension instead of the arrays?
You must be missing something...

Honestly, I'm not so sure
it's a good idea to implement it like PECL extension does. Filtering
individual variables is, in my opinion, a wrong way to treat user input.

You may filter data recursively, so filtering, for example, _POST or _GET would work fine.

Besides, is it really necessary to make input filtering a part of the
language?

An extension is not a part of the language, you may or may not compile it, while the language is still there.

It's a very high-level feature, and implementation may vary
according to the needs of the developer. Plus, it's perfectly doable in
pure PHP.

Yeah, that's why you can use your own callback for filtering.

In fact, I would go as far as removing session handling
functions from the "core" language too.

You're late.
Four or three years ago I'd agree with you, but it's too late for that.

--
Wbr,
Antony Dovgal

19 years ago by Roman Ivanov — view source

unread

Antony Dovgal wrote:

wishlist> input filter extension (including some element of user
wishlist> control)

Will it be used instead of $_POST and $_GET?

An extension instead of the arrays?
You must be missing something...

I do not think so. If the only way to get 'post' and 'get' variables
will be trough input_get(), then filter extension will effectively and
functionally replace those arrays. Is it not righ?

Honestly, I'm not so sure it's a good idea to implement it like PECL
extension does. Filtering individual variables is, in my opinion, a
wrong way to treat user input.

You may filter data recursively, so filtering, for example, _POST or
_GET would work fine.

Recursion does not solve the problem I'm trying to highlight.

//Way #1:
$filter = array(
'name' => '/^[\w\d]+$/',
'email' => RE_EMAIL,
'wage'=> new IntFilter(5, 500),
'phone'=>'/^\d{7,16}$/',
);
try {
$input = filterInput($filter);
} catch (InvalidField $e) {
user_error($e, E_USER_ERROR);
}

/--------------------------------------------/

//Way #2:
$name = input_get(INPUT_GET, 'name', FL_REGEXP, '/^[\w\d]+$/');
if ($name === NULL) {
user_error("Invalid 'name' field", E_USER_ERROR);
}
$email= input_get(INPUT_GET, 'email', FL_EMAIL);
if ($name === NULL) {
user_error("Invalid 'email' field", E_USER_ERROR);
}
$wage= input_get(INPUT_GET, 'wage', FL_INT, array('min_range' => 5,
'max_range' => 500));
if ($wage === NULL) {
user_error("Invalid 'wage' field", E_USER_ERROR);
}
$phone= input_get(INPUT_GET, 'phone', FL_REGEXP, '^\d{7,16}$');
if ($phone === NULL) {
user_error("Invalid 'phone' field", E_USER_ERROR);
}

Besides, is it really necessary to make input filtering a part of the
language?

An extension is not a part of the language, you may or may not compile
it, while the language is still there.

"Part of the standard API, which is included with PHP and compiles by
default", if you will.

It's a very high-level feature, and implementation may vary according
to the needs of the developer. Plus, it's perfectly doable in pure PHP.

Yeah, that's why you can use your own callback for filtering.

Callback just plugs your function in some pre-defined structure.

In fact, I would go as far as removing session handling functions from
the "core" language too.

You're late.
Four or three years ago I'd agree with you, but it's too late for that.

19 years ago by Antony Dovgal — view source

unread

Antony Dovgal wrote:

wishlist> input filter extension (including some element of user
wishlist> control)

Will it be used instead of $_POST and $_GET?

An extension instead of the arrays?
You must be missing something...

I do not think so. If the only way to get 'post' and 'get' variables
will be trough input_get(), then filter extension will effectively and
functionally replace those arrays. Is it not righ?

Obviously, no, this won't be the only way to get the data.

Honestly, I'm not so sure it's a good idea to implement it like PECL
extension does. Filtering individual variables is, in my opinion, a
wrong way to treat user input.

You may filter data recursively, so filtering, for example, _POST or
_GET would work fine.

Recursion does not solve the problem I'm trying to highlight.

//Way #1:

Didn't get the problem, sorry.
Could you try to explain it once more?

"Part of the standard API, which is included with PHP and compiles by
default", if you will.

So, basically you're objecting against enabling it by default?
Why? I really do not see a reason to not include it by default, if it helps to write more secure code.
(remember that "enabled by default" means you can disable it in a moment).

Yeah, that's why you can use your own callback for filtering.
Callback just plugs your function in some pre-defined structure.

Right.
Feel free to write your own PHP class/library for filtering, if you think that this predefined structure doesn't fit your needs.

--
Wbr,
Antony Dovgal

19 years ago by Roman Ivanov — view source

unread

Antony Dovgal wrote:

Obviously, no, this won't be the only way to get the data.

That's good.

Honestly, I'm not so sure it's a good idea to implement it like PECL
extension does. Filtering individual variables is, in my opinion, a
wrong way to treat user input.

You may filter data recursively, so filtering, for example, _POST or
_GET would work fine.

Recursion does not solve the problem I'm trying to highlight.

Didn't get the problem, sorry.
Could you try to explain it once more?

This particular extension treats each input variable individually, which
is not desirable in majority of scripts I worked with. Such approach
adds unnecessary complexity to the script, and requires to handle each
invalid variable separately as well. But the real problem is that there
are many ways of filtering input, and I do not think any of them fits
all the situations.

"Part of the standard API, which is included with PHP and compiles by
default", if you will.

So, basically you're objecting against enabling it by default?
Why? I really do not see a reason to not include it by default, if it
helps to write more secure code.
(remember that "enabled by default" means you can disable it in a
moment).

Well, I think that everything in core distribution is a suggested
standard. But a language should not, in my opinion, suggest any
particular structure for the program, unless it's absolutely necessary.
It's not a major issue, but still...

19 years ago by Antony Dovgal — view source

unread

This particular extension treats each input variable individually, which
is not desirable in majority of scripts I worked with. Such approach
adds unnecessary complexity to the script, and requires to handle each
invalid variable separately as well. But the real problem is that there
are many ways of filtering input, and I do not think any of them fits
all the situations.

Ahha.
So what exactly do you propose?
For example, I have 3 different variables: an email, an integer and a string.
How do you think I should filter them ?

"Part of the standard API, which is included with PHP and compiles by
default", if you will.

So, basically you're objecting against enabling it by default?
Why? I really do not see a reason to not include it by default, if it
helps to write more secure code.
(remember that "enabled by default" means you can disable it in a
moment).

Well, I think that everything in core distribution is a suggested
standard. But a language should not, in my opinion, suggest any
particular structure for the program, unless it's absolutely necessary.
It's not a major issue, but still...

Sorry, I refuse to understand that.
The language HAS to recommend a way to do something and to allow user to choose any other way if the recommended one doesn't fit his/her needs.
If there is no a recommended way to do, for example, input filtering, users would re-invent the wheel every time, which results in square wheels and engines with security issues discovered every day.
That's the whole point: to provide a fast and comfortable way to filter data, so the users won't have to do it themselves.

Feel free to offer an improvements, if you have something to offer, but saying that a standard method of doing something imposes a particular structure is just a nonsense.

--
Wbr,
Antony Dovgal

19 years ago by Roman Ivanov — view source

unread

Antony Dovgal wrote:

This particular extension treats each input variable individually,
which is not desirable in majority of scripts I worked with. Such
approach adds unnecessary complexity to the script, and requires to
handle each invalid variable separately as well. But the real problem
is that there are many ways of filtering input, and I do not think any
of them fits all the situations.

Ahha.
So what exactly do you propose?
For example, I have 3 different variables: an email, an integer and a
string.
How do you think I should filter them ?

Sorry, do not have time to simplify. This is how I do it:

function filterRequest($prototype, $action){
loadPrototype($prototype);
$vars = get_class_vars($prototype);
if ($vars['vigilant'] == FALSE) {
return $_REQUEST;
}

 $filter = getFilter($prototype, $action);
 if ($filter == NULL) {
     return NULL;
 }
 if ($filter == TRUE) {
     return $_REQUEST;
 }

 $cleanedVars = array();
 foreach ($filter as $fieldName => $rule) {
     if ($rule === TRUE) {
         $cleanedVars[$fieldName] = @$_REQUEST[$fieldName];
         continue;
     }// else {
         $positiveMatch = TRUE;
         if (preg_match('/n\w*$/', $rule)) { //check whether regExp

has n modifier
$positiveMatch = FALSE;
$rule = preg_replace('/n(\w*)$/', '$1', $rule);
//remove modifier so PHP won't complain
}
if (preg_match($rule, @$_REQUEST[$fieldName]) &&
$positiveMatch) {
$cleanedVars[$fieldName] = @$_REQUEST[$fieldName];
} else {
user_error("Request filtered out because of
'$fieldName' field", E_USER_WARNING);
return NULL;
}
//}
}
return $cleanedVars;
}

"Part of the standard API, which is included with PHP and compiles by
default", if you will.

So, basically you're objecting against enabling it by default?
Why? I really do not see a reason to not include it by default, if it
helps to write more secure code.
(remember that "enabled by default" means you can disable it in a
moment).

Well, I think that everything in core distribution is a suggested
standard. But a language should not, in my opinion, suggest any
particular structure for the program, unless it's absolutely
necessary. It's not a major issue, but still...

Sorry, I refuse to understand that.
The language HAS to recommend a way to do something and to allow user to
choose any other way if the recommended one doesn't fit his/her needs.

Perl: There is more than one way to do it.
Java: There is more than one way to do it, as long as you're doing it
our way.
C: Use assembly.

19 years ago by Michael Wallner — view source

unread

Hi Roman Ivanov, you wrote:

Sorry, do not have time to simplify. This is how I do it:

function filterRequest($prototype, $action){
loadPrototype($prototype);
$vars = get_class_vars($prototype);
if ($vars['vigilant'] == FALSE) {
return $_REQUEST;
}
$filter = getFilter($prototype, $action);
if ($filter == NULL) {
    return NULL;
}
if ($filter == TRUE) {
    return $_REQUEST;
}

If this is the code you're using, it's useless. Anything after those
two statements is "unreachable code", i.e. you do no filtering at all.

Regards,

Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz

19 years ago by Roman Ivanov — view source

unread

Michael Wallner wrote:

Hi Roman Ivanov, you wrote:

Sorry, do not have time to simplify. This is how I do it:

function filterRequest($prototype, $action){
loadPrototype($prototype);
$vars = get_class_vars($prototype);
if ($vars['vigilant'] == FALSE) {
return $_REQUEST;
}

$filter = getFilter($prototype, $action);
if ($filter == NULL) {
return NULL;
}
if ($filter == TRUE) {
return $_REQUEST;
}

If this is the code you're using, it's useless. Anything after those
two statements is "unreachable code", i.e. you do no filtering at all.

Yeah, need to replace == with ===. Thanks.

19 years ago by Cesare D'Amico — view source

unread

Alle 09:36, lunedì 14 novembre 2005, Lukas Smith ha scritto:

http://oss.backendmedia.com/PhP60

Bundle a default application server, ie a default way to hold
objects/variables in memory (on ANY operating system) between two HTTP
requests? Anyone interested?

Ciao
ce

Cesare D'Amico php developer - linux sysadmin
c . damico @ wyrd-software . com Key on pgp.mit.edu, ID 92802693
ICQ 66605157 - Skype cesaredamico - Mobile +39 320 0635 028
"If you always do what you've always done, you'll always get
what you've always got", and then wonder why nothing's changed

19 years ago by Cesare D'Amico — view source

unread

Alle 12:25, lunedì 14 novembre 2005, Cesare D'Amico ha scritto:

a default way to hold objects/variables in memory (on ANY operating
system) between two HTTP requests

Hey, I didn't mean sessions :)

I meant something like creating a complex object and holding it in
memory with its classes hierarchy, so I don't need to reload it all at
every single request.

Ciao

Cesare D'Amico php developer - linux sysadmin
c . damico @ wyrd-software . com Key on pgp.mit.edu, ID 92802693
ICQ 66605157 - Skype cesaredamico - Mobile +39 320 0635 028
"If you always do what you've always done, you'll always get
what you've always got", and then wonder why nothing's changed

19 years ago by Cesare D'Amico — view source

unread

Alle 14:58, lunedì 14 novembre 2005, Lukas Smith ha scritto:

You mean something like SRM:
http://www.vl-srm.net/

Though a bit more finished :-)

Exactly! I didn't mention it, but that's what I was thinking about.

And it would be nice if it was for PHP5 too :)

--
Cesare D'Amico php developer - linux sysadmin
c . damico @ wyrd-software . com Key on pgp.mit.edu, ID 92802693
ICQ 66605157 - Skype cesaredamico - Mobile +39 320 0635 028
"If you always do what you've always done, you'll always get
what you've always got", and then wonder why nothing's changed

19 years ago by Cesare D'Amico — view source

unread

Alle 21:10, lunedì 14 novembre 2005, Jani Taskinen ha scritto:

Exactly! I didn't mention it, but that's what I was thinking about.

IMO, no. (bundling SRM or any other such thing)

I don't want to bother, but why not? I'm accepting a simple RTFA (read
the friendly archives :) if that was discussed yet (but keep in mind
that this is a major number change).

Thanks, ciao
cesare

Cesare D'Amico php developer - linux sysadmin
c . damico @ wyrd-software . com Key on pgp.mit.edu, ID 92802693
ICQ 66605157 - Skype cesaredamico - Mobile +39 320 0635 028
"If you always do what you've always done, you'll always get
what you've always got", and then wonder why nothing's changed

19 years ago by Cesare D'Amico — view source

unread

Alle 22:05, lunedì 14 novembre 2005, Marcus Boerger ha scritto:

Simply because it is not the PHP way.
[...]
Thus PHP takes the KISS approach - keep it simple safe.

Fair enough, that's understandable :)

Thanks,
Cesare

Cesare D'Amico php developer - linux sysadmin
c . damico @ wyrd-software . com Key on pgp.mit.edu, ID 92802693
ICQ 66605157 - Skype cesaredamico - Mobile +39 320 0635 028
"If you always do what you've always done, you'll always get
what you've always got", and then wonder why nothing's changed

19 years ago by Cesare D'Amico — view source

unread

Alle 22:28, lunedì 14 novembre 2005, Rasmus Lerdorf ha scritto:

Until there is an implementation out there that is in common use, the
question of whether to bundle it or not is rather premature.

Until there is a standard (planned or de-facto) and widely installed
implementation (ie, one that is bundled with php ;) I doubt that any
will be in common use, at any time.

Anyway, Marcus' response was crystal clear, so I have nothing more to
argue :)

Thanks,
Cesare

Cesare D'Amico php developer - linux sysadmin
c . damico @ wyrd-software . com Key on pgp.mit.edu, ID 92802693
ICQ 66605157 - Skype cesaredamico - Mobile +39 320 0635 028
"If you always do what you've always done, you'll always get
what you've always got", and then wonder why nothing's changed

19 years ago by Roman Ivanov — view source

unread

Rasmus Lerdorf wrote:

I don't think you understand the order of operations here. We can't
bundle something that doesn't exist.

You can state your opinion regarding probability of something being
bundled in the future. This will encourage people to actually write it.

19 years ago by Cesare D'Amico — view source

unread

Alle 22:53, lunedì 14 novembre 2005, Rasmus Lerdorf ha scritto:

I think you are looking for an option 3 here. You are stating
a need and hoping someone will write something.

Yes, I admit that without any regret ;)

But I do understand how things work. I tried to propose that idea
because I'd like to see it implemented, but I don't have sufficient C
skills nor time, so I just wanted to see if there was any interest (by
some "real" developer :) in realizing it.

There's no big interest, a pity, but that's ok, that's how things
work :)

Ciao, thanks
ce

Cesare D'Amico php developer - linux sysadmin
c . damico @ wyrd-software . com Key on pgp.mit.edu, ID 92802693
ICQ 66605157 - Skype cesaredamico - Mobile +39 320 0635 028
"If you always do what you've always done, you'll always get
what you've always got", and then wonder why nothing's changed

results of the PHP6 wishlists

Regards,

Ciao ce

Ciao

Thanks, ciao cesare

Thanks, Cesare

Thanks, Cesare

Ciao, thanks ce

Ciao
ce

Thanks, ciao
cesare

Thanks,
Cesare

Thanks,
Cesare

Ciao, thanks
ce