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
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
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.
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.
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
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.
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.
<skip> > //Way #2: <skip>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
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...
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
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.
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
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.
Alle 09:36, lunedì 14 novembre 2005, Lukas Smith ha scritto:
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
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