Issue status update for http://drupal.org/node/25745 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: adrian Reported by: adrian Updated by: killes@www.drop.org Status: patch While I like the idea as such, I'd like to see that the form fields that are affected by such global variables should be disabled. Otherwise we'll have a lot of confused users/ support requests. killes@www.drop.org Previous comments: ------------------------------------------------------------------------ June 25, 2005 - 15:57 : adrian Attachment: http://drupal.org/files/issues/variable_default.patch (0 bytes) When running a mass hosting environment, it is often required to shield users from the ability to break the sites hosted on your system and there are very often also good security reasons to remove the ability to configure certain variables. This patch does two things : 1) Introduces an optional sites/global.php file, that will be loaded after the sites/default/settings.php file and provide a set of global settings for all sites hosted on a server. This means the administrator only needs to configure the variables once. 2) Modifies variable_get and variable_set to check optional 'variable_default($name)' and 'variable_override($name)' functions, that an administrator can define in the above global.php file. There already exists the ability to set variables using $conf[varname] in your settings.php file, but there is no distinction made against variables that have been set this way, and normal variables, apart from the fact that trying to change them in the admin section fails silently. A good example of this would be the need to set up the files dir, and not allow it to be modified, as a user modifying the files dir to another site's files directory could be catastrophic. <?php   function variable_override($name) {     $conf['file_directory_path'] = conf_init() . '/files';     $conf['file_directory_temp'] = conf_init() . '/files/tmp';     $conf['file_downloads'] = 2;     return $conf[$name];   } ?> These values will now be the only accepted and used values to the variables. If the user tries to modify them, they will revert to these values and there will be a message stating that the variable has been locked. Another common requirement is to provide sensible defaults for an install, but not take away the configurability of the option. A common example of this would be the theme setting. <?php   function variable_default($name) {     $conf['theme_default'] = 'chameleon';      return $conf[$name];   } ?> This will change the default that variable_get falls back on, from the one provided in the parameter list, to the administrator configured default. This is a much cleaner method of setting the defaults, than global search replacing the defaults provided in the code. This patch is one of the changes we have made to the drupal code base for our hosting platform @ bryght.

Issue status update for http://drupal.org/node/25745 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: adrian Reported by: adrian Updated by: killes@www.drop.org Status: patch Heh, ok, let's push this patch in core. But I suggest you upload it again, I can't look at it for some reason. killes@www.drop.org Previous comments: ------------------------------------------------------------------------ June 25, 2005 - 15:57 : adrian Attachment: http://drupal.org/files/issues/variable_default.patch (0 bytes) When running a mass hosting environment, it is often required to shield users from the ability to break the sites hosted on your system and there are very often also good security reasons to remove the ability to configure certain variables. This patch does two things : 1) Introduces an optional sites/global.php file, that will be loaded after the sites/default/settings.php file and provide a set of global settings for all sites hosted on a server. This means the administrator only needs to configure the variables once. 2) Modifies variable_get and variable_set to check optional 'variable_default($name)' and 'variable_override($name)' functions, that an administrator can define in the above global.php file. There already exists the ability to set variables using $conf[varname] in your settings.php file, but there is no distinction made against variables that have been set this way, and normal variables, apart from the fact that trying to change them in the admin section fails silently. A good example of this would be the need to set up the files dir, and not allow it to be modified, as a user modifying the files dir to another site's files directory could be catastrophic. <?php   function variable_override($name) {     $conf['file_directory_path'] = conf_init() . '/files';     $conf['file_directory_temp'] = conf_init() . '/files/tmp';     $conf['file_downloads'] = 2;     return $conf[$name];   } ?> These values will now be the only accepted and used values to the variables. If the user tries to modify them, they will revert to these values and there will be a message stating that the variable has been locked. Another common requirement is to provide sensible defaults for an install, but not take away the configurability of the option. A common example of this would be the theme setting. <?php   function variable_default($name) {     $conf['theme_default'] = 'chameleon';      return $conf[$name];   } ?> This will change the default that variable_get falls back on, from the one provided in the parameter list, to the administrator configured default. This is a much cleaner method of setting the defaults, than global search replacing the defaults provided in the code. This patch is one of the changes we have made to the drupal code base for our hosting platform @ bryght. ------------------------------------------------------------------------ June 25, 2005 - 21:47 : killes@www.drop.org While I like the idea as such, I'd like to see that the form fields that are affected by such global variables should be disabled. Otherwise we'll have a lot of confused users/ support requests. ------------------------------------------------------------------------ June 25, 2005 - 21:52 : adrian I agree with you .. unfortunately i don't think it's currently possible. It might be closer to possible with the new forms patch, but I don't think that's a suitable reason for this patch not to go in. I use form_set_error to display the locked variable message, so it already shows which form items have been disabled, but only after you try to change them.

Issue status update for http://drupal.org/node/25745 Post a follow up: http://drupal.org/project/comments/add/25745 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: adrian Reported by: adrian Updated by: Jose A Reyero Status: patch (code needs review) I think the idea it's interesting, but the idea would be really useful the other way: having a global configuration that can be overridden by specific site settings.

From a security standpoing you've lost the battle from the beginning, since the admin of a site can create a PHP page and add some db_query code.

And I dont like too much having functions in the config file. Maybe better having $conf, $default, $fixed arrays in that files, and then the variable code handling that. So +1 to having that global.php settings file, but should be before settings php, and -1 to the rest of the patch. Patch bingo :-) Jose A Reyero Previous comments: ------------------------------------------------------------------------ Sat, 25 Jun 2005 13:57:26 +0000 : adrian Attachment: http://drupal.org/files/issues/variable_default.patch (0 bytes) When running a mass hosting environment, it is often required to shield users from the ability to break the sites hosted on your system and there are very often also good security reasons to remove the ability to configure certain variables. This patch does two things : 1) Introduces an optional sites/global.php file, that will be loaded after the sites/default/settings.php file and provide a set of global settings for all sites hosted on a server. This means the administrator only needs to configure the variables once. 2) Modifies variable_get and variable_set to check optional 'variable_default($name)' and 'variable_override($name)' functions, that an administrator can define in the above global.php file. There already exists the ability to set variables using $conf[varname] in your settings.php file, but there is no distinction made against variables that have been set this way, and normal variables, apart from the fact that trying to change them in the admin section fails silently. A good example of this would be the need to set up the files dir, and not allow it to be modified, as a user modifying the files dir to another site's files directory could be catastrophic. <?php   function variable_override($name) {     $conf['file_directory_path'] = conf_init() . '/files';     $conf['file_directory_temp'] = conf_init() . '/files/tmp';     $conf['file_downloads'] = 2;     return $conf[$name];   } ?> These values will now be the only accepted and used values to the variables. If the user tries to modify them, they will revert to these values and there will be a message stating that the variable has been locked. Another common requirement is to provide sensible defaults for an install, but not take away the configurability of the option. A common example of this would be the theme setting. <?php   function variable_default($name) {     $conf['theme_default'] = 'chameleon';      return $conf[$name];   } ?> This will change the default that variable_get falls back on, from the one provided in the parameter list, to the administrator configured default. This is a much cleaner method of setting the defaults, than global search replacing the defaults provided in the code. This patch is one of the changes we have made to the drupal code base for our hosting platform @ bryght. ------------------------------------------------------------------------ Sat, 25 Jun 2005 19:47:16 +0000 : killes@www.drop.org While I like the idea as such, I'd like to see that the form fields that are affected by such global variables should be disabled. Otherwise we'll have a lot of confused users/ support requests. ------------------------------------------------------------------------ Sat, 25 Jun 2005 19:52:18 +0000 : adrian I agree with you .. unfortunately i don't think it's currently possible. It might be closer to possible with the new forms patch, but I don't think that's a suitable reason for this patch not to go in. I use form_set_error to display the locked variable message, so it already shows which form items have been disabled, but only after you try to change them. ------------------------------------------------------------------------ Sat, 25 Jun 2005 19:56:20 +0000 : killes@www.drop.org Heh, ok, let's push this patch in core. But I suggest you upload it again, I can't look at it for some reason. ------------------------------------------------------------------------ Wed, 29 Jun 2005 11:22:50 +0000 : adrian Attachment: http://drupal.org/files/issues/variable_default_0.patch (2.25 KB) uploaded again

Issue status update for http://drupal.org/node/25745 Post a follow up: http://drupal.org/project/comments/add/25745 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: adrian Reported by: adrian Updated by: adrian -Status: patch (code needs review) +Status: patch (code needs work) changing status applicably adrian Previous comments: ------------------------------------------------------------------------ Sat, 25 Jun 2005 13:57:26 +0000 : adrian Attachment: http://drupal.org/files/issues/variable_default.patch (0 bytes) When running a mass hosting environment, it is often required to shield users from the ability to break the sites hosted on your system and there are very often also good security reasons to remove the ability to configure certain variables. This patch does two things : 1) Introduces an optional sites/global.php file, that will be loaded after the sites/default/settings.php file and provide a set of global settings for all sites hosted on a server. This means the administrator only needs to configure the variables once. 2) Modifies variable_get and variable_set to check optional 'variable_default($name)' and 'variable_override($name)' functions, that an administrator can define in the above global.php file. There already exists the ability to set variables using $conf[varname] in your settings.php file, but there is no distinction made against variables that have been set this way, and normal variables, apart from the fact that trying to change them in the admin section fails silently. A good example of this would be the need to set up the files dir, and not allow it to be modified, as a user modifying the files dir to another site's files directory could be catastrophic. <?php   function variable_override($name) {     $conf['file_directory_path'] = conf_init() . '/files';     $conf['file_directory_temp'] = conf_init() . '/files/tmp';     $conf['file_downloads'] = 2;     return $conf[$name];   } ?> These values will now be the only accepted and used values to the variables. If the user tries to modify them, they will revert to these values and there will be a message stating that the variable has been locked. Another common requirement is to provide sensible defaults for an install, but not take away the configurability of the option. A common example of this would be the theme setting. <?php   function variable_default($name) {     $conf['theme_default'] = 'chameleon';      return $conf[$name];   } ?> This will change the default that variable_get falls back on, from the one provided in the parameter list, to the administrator configured default. This is a much cleaner method of setting the defaults, than global search replacing the defaults provided in the code. This patch is one of the changes we have made to the drupal code base for our hosting platform @ bryght. ------------------------------------------------------------------------ Sat, 25 Jun 2005 19:47:16 +0000 : killes@www.drop.org While I like the idea as such, I'd like to see that the form fields that are affected by such global variables should be disabled. Otherwise we'll have a lot of confused users/ support requests. ------------------------------------------------------------------------ Sat, 25 Jun 2005 19:52:18 +0000 : adrian I agree with you .. unfortunately i don't think it's currently possible. It might be closer to possible with the new forms patch, but I don't think that's a suitable reason for this patch not to go in. I use form_set_error to display the locked variable message, so it already shows which form items have been disabled, but only after you try to change them. ------------------------------------------------------------------------ Sat, 25 Jun 2005 19:56:20 +0000 : killes@www.drop.org Heh, ok, let's push this patch in core. But I suggest you upload it again, I can't look at it for some reason. ------------------------------------------------------------------------ Wed, 29 Jun 2005 11:22:50 +0000 : adrian Attachment: http://drupal.org/files/issues/variable_default_0.patch (2.25 KB) uploaded again ------------------------------------------------------------------------ Mon, 05 Sep 2005 14:41:42 +0000 : Jose A Reyero I think the idea it's interesting, but the idea would be really useful the other way: having a global configuration that can be overridden by specific site settings.

From a security standpoing you've lost the battle from the beginning, since the admin of a site can create a PHP page and add some db_query code.

And I dont like too much having functions in the config file. Maybe better having $conf, $default, $fixed arrays in that files, and then the variable code handling that. So +1 to having that global.php settings file, but should be before settings php, and -1 to the rest of the patch. Patch bingo :-) ------------------------------------------------------------------------ Mon, 05 Sep 2005 15:47:28 +0000 : adrian I need to update the patch, once I have the form stuff done .. since I am planning to filter out the overriden elements on settings pages, meaning they can't be accessed from the interface. Also, the general idea has been changed to having "$default", and "$override" global variables. Dries has vetoed the global configuration file though, saying we should just add it to our config file when neccesary.