Hi,
What do you think about that :
function getPOST($name) { global $_POST; if(is_set($_POST[$name])) { if(get_magic_quotes_gpc () == 1) return *stripslashes(*$_POST[$name]); else return $_POST[$name]; } return null; }
same thing for $_GET we only need to change all $_GET and $_POST.
I think it's more easy than playing with .htaccess or php.ini.
If you agree, I'll do it tonight.
David
Instead of that, using this:
if(!get_magic_quotes_gpc()){ function deepslash($v){ return (is_array($v)) ? array_map("deepslash", $v) : addslashes($v); } $_POST=array_map("deepslash", $_POST); $_GET=array_map("deepslash", $_GET); $_COOKIE=array_map("deepslash", $_COOKIE); $_REQUEST=array_map("deepslash", $_REQUEST); $_GLOBALS=array_map("deepslash", $_GLOBALS); $_SERVER=array_map("deepslash", $_SERVER);
}
taken from here: http://us2.php.net/manual/en/function.get-magic-quotes-gpc.php Should work much better and you only need to put it at the top of one of the main include files instead of modifying the entire codebase.
-Charles
dc.ml@oxys.net wrote:
Hi,
What do you think about that :
function getPOST($name) { global $_POST; if(is_set($_POST[$name])) { if(get_magic_quotes_gpc () == 1) return *stripslashes(*$_POST[$name]); else return $_POST[$name]; } return null; }
same thing for $_GET we only need to change all $_GET and $_POST.
I think it's more easy than playing with .htaccess or php.ini.
If you agree, I'll do it tonight.
David
Also there are many other examples of dealing with this problem at: http://us2.php.net/manual/en/function.get-magic-quotes-gpc.php that may be better than the one I pasted in in my last e-mail. In any case, I highly recommend we use one of the solutions that rewrites the $_POST array rather than a solution that requires using a function for every use of a POST variable.
-Charles
dc.ml@oxys.net wrote:
Hi,
What do you think about that :
function getPOST($name) { global $_POST; if(is_set($_POST[$name])) { if(get_magic_quotes_gpc () == 1) return *stripslashes(*$_POST[$name]); else return $_POST[$name]; } return null; }
same thing for $_GET we only need to change all $_GET and $_POST.
I think it's more easy than playing with .htaccess or php.ini.
If you agree, I'll do it tonight.
David
I'm not sure it's a good solution for people with mogic_quote set to 'On' because we will do lot of change on variable we will never access, but it's the easiest ;o)
Charles McNulty a écrit :
Also there are many other examples of dealing with this problem at: http://us2.php.net/manual/en/function.get-magic-quotes-gpc.php that may be better than the one I pasted in in my last e-mail. In any case, I highly recommend we use one of the solutions that rewrites the $_POST array rather than a solution that requires using a function for every use of a POST variable.
On Tue, Feb 07, 2006 at 08:01:27PM +0100, David Charbonnier wrote:
I'm not sure it's a good solution for people with mogic_quote set to 'On' because we will do lot of change on variable we will never access, but it's the easiest ;o)
Charles McNulty a ??crit :
Also there are many other examples of dealing with this problem at: http://us2.php.net/manual/en/function.get-magic-quotes-gpc.php that may be better than the one I pasted in in my last e-mail. In any case, I highly recommend we use one of the solutions that rewrites the $_POST array rather than a solution that requires using a function for every use of a POST variable.
The best solution would have been for magic quotes to never have existed in the first place.
On Tue, Feb 07, 2006 at 03:00:04PM -0600, Steve Block wrote:
The best solution would have been for magic quotes to never have existed in the first place.
Amen.
I suggested something like this a while ago: http://lists.roundcube.net/mail-archive/roundcube.dev/2006/01/2/
Balu
This solution is easy to add, of course, but it does a lot of things that are probably not necessary. I'd prefer a generic function like get_form_input($name) which does something like the solution posted by dc.ml[at]oxys.net but with also with GET parameters: $in = !empty($_POST[$name]) ? $_POST[$name] : $_GET[$name];
Regards, Thomas
Charles McNulty wrote:
Instead of that, using this:
if(!get_magic_quotes_gpc()){ function deepslash($v){ return (is_array($v)) ? array_map("deepslash", $v) : addslashes($v); } $_POST=array_map("deepslash", $_POST); $_GET=array_map("deepslash", $_GET); $_COOKIE=array_map("deepslash", $_COOKIE); $_REQUEST=array_map("deepslash", $_REQUEST); $_GLOBALS=array_map("deepslash", $_GLOBALS); $_SERVER=array_map("deepslash", $_SERVER);
}
taken from here: http://us2.php.net/manual/en/function.get-magic-quotes-gpc.php Should work much better and you only need to put it at the top of one of the main include files instead of modifying the entire codebase.
-Charles
dc.ml@oxys.net wrote:
Hi,
What do you think about that :
function getPOST($name) { global $_POST; if(is_set($_POST[$name])) { if(get_magic_quotes_gpc () == 1) return *stripslashes(*$_POST[$name]); else return $_POST[$name]; } return null; }
same thing for $_GET we only need to change all $_GET and $_POST.
I think it's more easy than playing with .htaccess or php.ini.
If you agree, I'll do it tonight.
David
Thomas Bruederli a écrit :
but it does a lot of things that are probably not necessary.
true
I'd prefer a generic function like get_form_input($name) which does something like the solution posted by dc.ml[at]oxys.net but with also with GET parameters: $in = !empty($_POST[$name]) ? $_POST[$name] : $_GET[$name];
I don't like the idea to don't know from which method are data. I don't use $_REQUEST and your solution is $_REQUEST equivalent.
If you prefer, we can do get_input($name,$method='A') 'A' is for All with EGPCS order, and the equivalent of your code should be 'PG'
PS : Who are official devellopers with write access to cvs ? Patch to improve RFC2822 compliance on reply messages have not been applied. Who can I ask ?
David Charbonnier wrote:
Thomas Bruederli a écrit :
but it does a lot of things that are probably not necessary.
true
I'd prefer a generic function like get_form_input($name) which does something like the solution posted by dc.ml[at]oxys.net but with also with GET parameters: $in = !empty($_POST[$name]) ? $_POST[$name] : $_GET[$name];
I don't like the idea to don't know from which method are data. I don't use $_REQUEST and your solution is $_REQUEST equivalent.
If you prefer, we can do get_input($name,$method='A') 'A' is for All with EGPCS order, and the equivalent of your code should be 'PG'
Agree. This would be a good solution.
PS : Who are official devellopers with write access to cvs ? Patch to improve RFC2822 compliance on reply messages have not been applied. Who can I ask ?
All developers listed here: http://sourceforge.net/project/memberlist.php?group_id=139281
I have very little time at the moment and I'm not able to add patches daily. But this does not mean, that they will not be added.
Also I'm willing to add more people as developers in order to have patches added to the repository. Just send me your Sourceforge user name if you're interested.
Regards, Thomas
I'd prefer a generic function like get_form_input($name) which does something like the solution posted by dc.ml[at]oxys.net but with also with GET parameters: $in = !empty($_POST[$name]) ? $_POST[$name] : $_GET[$name];
I don't like the idea to don't know from which method are data. I don't use $_REQUEST and your solution is $_REQUEST equivalent.
If you prefer, we can do get_input($name,$method='A') 'A' is for All with EGPCS order, and the equivalent of your code should be 'PG'
Agree. This would be a good solution.
So ? I do it ? Does everybody approve this solution ?
David
David Charbonnier wrote:
I'd prefer a generic function like get_form_input($name) which does something like the solution posted by dc.ml[at]oxys.net but with also with GET parameters: $in = !empty($_POST[$name]) ? $_POST[$name] : $_GET[$name];
I don't like the idea to don't know from which method are data. I don't use $_REQUEST and your solution is $_REQUEST equivalent.
If you prefer, we can do get_input($name,$method='A') 'A' is for All with EGPCS order, and the equivalent of your code should be 'PG'
Agree. This would be a good solution.
So ? I do it ? Does everybody approve this solution ?
You're welcome to implement this. I guess this function would mainly be used in the following steps: program/steps/mail/sendmail.inc program/steps/settings/save_identity.inc program/steps/addressbook/save.inc
Just send me your Sourceforge name to get access to the CVS.
David
Thanks! Thomas
The problem I see with this implementation has to do with code readability and maintenance. There are two very nice things about using the POST and GET variables directly instead of copying them into a separate variable. First is that it will be easy to forget this step and it is likely to be implemented unevenly. That is, for new developers they are likely to just use _POST or _GET instead of using the get_input function.
The second is that for code readability, you lose the context of the variable when you copy it into another variable. Now instead of being able to easily see that a variable is part of the POST array, I have to look around and see if the post variable has been copied into that variable.
Am I all alone in thinking that uniformly removing or adding all slashes to the POST and GET variables once at the top of the program is a better implementation than modifying every line of code that uses these variables?
-Charles
David Charbonnier wrote:
I'd prefer a generic function like get_form_input($name) which does something like the solution posted by dc.ml[at]oxys.net but with also with GET parameters: $in = !empty($_POST[$name]) ? $_POST[$name] : $_GET[$name];
I don't like the idea to don't know from which method are data. I don't use $_REQUEST and your solution is $_REQUEST equivalent.
If you prefer, we can do get_input($name,$method='A') 'A' is for All with EGPCS order, and the equivalent of your code should be 'PG'
Agree. This would be a good solution.
So ? I do it ? Does everybody approve this solution ?
David
Charles McNulty schrieb:
Am I all alone in thinking that uniformly removing or adding all slashes to the POST and GET variables once at the top of the program is a better implementation than modifying every line of code that uses these variables?
i agree with you, i just would go one step further and introduce a warning depending on a configuration setting.
e.g. // BE WARNED, this setting is just a workaround, consider deactivating // magic_quotes_gpc in your php.ini // setting this option to TRUE will remove the warning displayed if // you have magic_quotes set to on. $rcmail_config['display_warning on_use_magic_quotes'] = FALSE;
if rc detects magic_quotes_gpc=on always do the workaround and display always a warning but with a hint, where to deactivate this warning. This way we spread the information about the magic_quotes problem and reduce support questions.
Kind regards
Florian Sperber
On Wed, Feb 08, 2006 at 03:35:35PM +0100, Florian Sperber wrote:
if rc detects magic_quotes_gpc=on always do the workaround and display always a warning but with a hint, where to deactivate this warning. This way we spread the information about the magic_quotes problem and reduce support questions.
Problem is that many scripts rely on magic_quotes_gpc=on. Even most PHP sites say that magic_quotes is a very important setting, because it helps avoiding security problems in scripts (which is totally wrong :-/).
If you tell people to switch that off, they might get problems with other scripts.
Balu
On Thu, 9 Feb 2006, Thomas -Balu- Walter wrote:
On Wed, Feb 08, 2006 at 03:35:35PM +0100, Florian Sperber wrote:
if rc detects magic_quotes_gpc=on always do the workaround and display always a warning but with a hint, where to deactivate this warning. This way we spread the information about the magic_quotes problem and reduce support questions.
Problem is that many scripts rely on magic_quotes_gpc=on. Even most PHP sites say that magic_quotes is a very important setting, because it helps avoiding security problems in scripts (which is totally wrong :-/).
If you tell people to switch that off, they might get problems with other scripts.
They can always have diferent settings for diferent directory definitions in the web server.
As I said before, magic_quotes is a very bad thing, and security must come from the programmer, not an automatic quoter.
-- 10:20:01 up 17 days, 16:05, 1 user, load average: 0.02, 0.02, 0.00
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
On Thu, Feb 09, 2006 at 10:26:53AM -0300, Lic. Martin Marques wrote:
On Thu, 9 Feb 2006, Thomas -Balu- Walter wrote:
If you tell people to switch that off, they might get problems with other scripts.
They can always have diferent settings for diferent directory definitions in the web server.
As I said before, magic_quotes is a very bad thing, and security must come from the programmer, not an automatic quoter.
I absolutely agree with you here. But the programmer should also make his software user/admin friendly and I don't think the 5 lines workaround needed to fix this problem are too much hassle for the coder...
You will have more problems telling website-"admins" (which usually don't know a bit of webserver administration) to change a PHP setting - just for this subdirectory - been there, done that ;).
Balu
On Thu, 9 Feb 2006, Thomas -Balu- Walter wrote:
I absolutely agree with you here. But the programmer should also make his software user/admin friendly and I don't think the 5 lines workaround needed to fix this problem are too much hassle for the coder...
You will have more problems telling website-"admins" (which usually don't know a bit of webserver administration) to change a PHP setting - just for this subdirectory - been there, done that ;).
Well, the solution could be (haven't followed the thread, so I don't know if it has already been posted) to add the php variable change in the .htaccess of RC.
Even with this, we should keep on insisting on web site administrators to have magic_quotes = off
-- 10:50:01 up 17 days, 16:35, 1 user, load average: 0.00, 0.01, 0.00
Lic. Martín Marqués | SELECT 'mmarques' || Centro de Telemática | '@' || 'unl.edu.ar'; Universidad Nacional | DBA, Programador, del Litoral | Administrador
On Thu, 9 Feb 2006 14:48:17 +0100, Thomas -Balu- Walter list+roundcube-dev@b-a-l-u.de wrote:
On Thu, Feb 09, 2006 at 10:26:53AM -0300, Lic. Martin Marques wrote:
On Thu, 9 Feb 2006, Thomas -Balu- Walter wrote:
If you tell people to switch that off, they might get problems with other scripts.
They can always have diferent settings for diferent directory
definitions
in the web server.
As I said before, magic_quotes is a very bad thing, and security must come from the programmer, not an automatic quoter.
I absolutely agree with you here. But the programmer should also make his software user/admin friendly and I don't think the 5 lines workaround needed to fix this problem are too much hassle for the coder...
You will have more problems telling website-"admins" (which usually don't know a bit of webserver administration) to change a PHP setting - just for this subdirectory - been there, done that ;).
In drupal the distributed .htaccess has the following:
# Override PHP settings. More exist in sites/default/settings.php, but # the following cannot be changed at runtime.
<IfModule sapi_apache2.c> php_value magic_quotes_gpc 0 php_value register_globals 0 php_value session.auto_start 0 </IfModule>
Wound something like that work here? I'd rather have RC decide how RC is going to work than have people go out and tweak their php.ini.
P
http://fak3r.com - you don\'t have to kick it
On Thu, 9 Feb 2006 9:55:57 -0600, phil phil@cryer.us wrote:
On Thu, 9 Feb 2006 14:48:17 +0100, Thomas -Balu- Walter list+roundcube-dev@b-a-l-u.de wrote:
On Thu, Feb 09, 2006 at 10:26:53AM -0300, Lic. Martin Marques wrote:
On Thu, 9 Feb 2006, Thomas -Balu- Walter wrote:
If you tell people to switch that off, they might get problems with other scripts.
They can always have diferent settings for diferent directory
definitions
in the web server.
As I said before, magic_quotes is a very bad thing, and security must come from the programmer, not an automatic quoter.
I absolutely agree with you here. But the programmer should also make his software user/admin friendly and I don\'t think the 5 lines workaround needed to fix this problem are too much hassle for the coder...
You will have more problems telling website-\"admins\" (which usually don\'t know a bit of webserver administration) to change a PHP setting - just for this subdirectory - been there, done that ;).
In drupal the distributed .htaccess has the following:
# Override PHP settings. More exist in sites/default/settings.php, but # the following cannot be changed at runtime.
<IfModule sapi_apache2.c> php_value magic_quotes_gpc 0 php_value register_globals 0 php_value session.auto_start 0 </IfModule>
"...to disable magic quotes completely, without the need to adjust your php.ini file or (re)process the user's input. [...] in the .htaccess file, add a line"
php_flag magic_quotes_gpc off
http://us3.php.net/manual/en/security.magicquotes.php#61589
P
http://fak3r.com - you don't have to kick it
On Thu, Feb 09, 2006 at 09:55:57AM -0600, phil wrote:
In drupal the distributed .htaccess has the following:
# Override PHP settings. More exist in sites/default/settings.php, but # the following cannot be changed at runtime.
<IfModule sapi_apache2.c> php_value magic_quotes_gpc 0 php_value register_globals 0 php_value session.auto_start 0 </IfModule>
Wound something like that work here? I'd rather have RC decide how RC is going to work than have people go out and tweak their php.ini.
There are webservers that don't support .htaccess files, so those are not a solution. Even worse - many shared hosting webservers don't allow changing options in .htaccess files. In this case the user will get an error message from the apache when trying to call the pages.
This is why I already wrote about the .htaccess-files that are included by default in the distribution.
I don't see the reason for this discussion anyway. There is an easy fix for the problem and we can and probably should tell people to switch magic_quotes off - in the readme or install documentation, but not as a warning message.
Many people do not understand those warnings and think that they mean the program was coded badly and just uninstall it.
Balu
PS: Some days ago I wrote about an "administrative info" page that could check server capabilities and notify the admin why some features do not work, check directory rights, etc.. You could also check magic_quotes there and print a nice description what is "wrong" and how people might be able to fix that.
On Thu, 9 Feb 2006 10:07:46 -0600, phil phil@cryer.us wrote:
On Thu, 9 Feb 2006 9:55:57 -0600, phil phil@cryer.us wrote:
On Thu, 9 Feb 2006 14:48:17 +0100, Thomas -Balu- Walter list+roundcube-dev@b-a-l-u.de wrote:
On Thu, Feb 09, 2006 at 10:26:53AM -0300, Lic. Martin Marques wrote:
On Thu, 9 Feb 2006, Thomas -Balu- Walter wrote:
If you tell people to switch that off, they might get problems with other scripts.
They can always have diferent settings for diferent directory
definitions
in the web server.
As I said before, magic_quotes is a very bad thing, and security must come from the programmer, not an automatic quoter.
I absolutely agree with you here. But the programmer should also make his software user/admin friendly and I don\\\'t think the 5 lines workaround needed to fix this problem are too much hassle for the coder...
You will have more problems telling website-\\\"admins\\\" (which
usually
don\\\'t know a bit of webserver administration) to change a PHP
setting -
just for this subdirectory - been there, done that ;).
Hey, am I the only one seeing this? See how in all of my msgs that go through Roundcube I'm getting all of the quotes or single quotes escaped by a backwards slash? Notice that it does it each time the reply is included, so some of the above are getting silly looking with 4-5 slashes in front of the quotes. Of course you'll see a new one in my sig too. Today I deleted my RC directory and did a fresh checkout, modified the db and main files in config, but outside of that it's all stock. Wondering if it's just me (and I need to look at my server) or what. I don't think it's my server b/c I don't think other users are getting this running Squirrel.
P
http://fak3r.com - you don't have to kick it
On tor, 2006-02-09 at 10:21 -0600, phil wrote:
Hey, am I the only one seeing this? See how in all of my msgs that go through Roundcube I'm getting all of the quotes or single quotes escaped by a backwards slash? Notice that it does it each time the reply is included, so some of the above are getting silly looking with 4-5 slashes in front of the quotes. Of course you'll see a new one in my sig too. Today I deleted my RC directory and did a fresh checkout, modified the db and main files in config, but outside of that it's all stock. Wondering if it's just me (and I need to look at my server) or what. I don't think it's my server b/c I don't think other users are getting this running Squirrel.
You're definitely not the only one seeing it.
I thought that was what was being discussed in the magic_quotes thread, but then I haven't really paid attention to it.
/Håkan
On 9 Feb 2006, at 16:11, Thomas -Balu- Walter wrote:
On Thu, Feb 09, 2006 at 09:55:57AM -0600, phil wrote:
In drupal the distributed .htaccess has the following:
<IfModule sapi_apache2.c> [...] </IfModule> Wound something like that work here? I\'d rather have RC decide how RC is going to work than have people go out and tweak their php.ini.
There are webservers that don't support .htaccess files, so those are not a solution. Even worse - many shared hosting webservers don't
allow changing options in .htaccess files. In this case the user will get an error message from the apache when trying to call the pages.
Just wanted to throw in my 2 cents and say that even on servers that
do support .htaccess, if php is used as a cgi it won't pay attention
to the php_value settings.
Yours, Craig -- Craig Webster | t: +44 (0)131 516 8595 | e: craig@xeriom.net Xeriom.NET | f: +44 (0)131 661 0689 | w: http://xeriom.net
-
Charles McNulty -
Craig Webster -
David Charbonnier -
dc.ml＠oxys.net -
Florian Sperber -
Håkan Lindqvist -
Lic. Martin Marques -
phil -
Steve Block -
Thomas -Balu- Walter -
Thomas Bruederli