On Sunday 29 January 2006 10:31, Adrian Rossouw wrote:
Ugh, holy crap, please no. Let me shoot myself in the foot, but don't force me to fucking load an FTP client. I thought this was a content management system - if I'm forced to a) write my content in a text editor, b) upload it through an FTP program, c) THEN manage it in the CMS, Drupal just isn't useful to me anymore.
I completely agree with that.
+1 from here (that is, +1 for keeping PHP pages integral to core). I know how to write modules, but there are times when a PHP page gets the job done faster. Remember that a "PHP page" doesn't have to be all PHP, and it doesn't even have to access Drupal functionality. Maybe the PHP page is mostly HTML code with just a couple of print() statements to echo out system variables -- like a page that lets the user behind a firewall find out their external IP address, for instance. Also, what if the PHP page is temporary? Who wants to write a module to support some special feature that's only needed for a week, say during a server migration? As long as, by default, normal users can't create PHP pages (that is, all roles' access for this content type is turned off, so only user #1 can create or edit PHP), I don't see a problem with security. Novices aren't going to know how to create PHP code in the first place, and advanced users should operate under the principle of "your gun, your bullet, your foot, your choice." Open Source is not about protecting me from myself. If user #1 is dumb enough to grant PHP page permissions to "anonymous user" then they deserve what they get. (Should we document this on the settings page? Yes. Should we block it from happening? Maybe. I could _potentially_ even support a proposal to hardwire the PHP filter so that it is always "user #1 only" access, but I'd want to think about it first.)
I do also however agree with making the php filter a separate filter and not including/installing it by default.
This won't help security, IMO. Again, novices won't be creating PHP no matter how easy or how hard you make it. Advanced users know what they are doing and will create _good_ PHP. The intermediate user who knows how to create PHP but not how to create good PHP won't be deterred by merely having to put it into a separate file instead of typing it into the CMS -- these users know how to use FTP. IMO, all this proposal does is to make it less convenient for those who want to use PHP pages, while doing nothing to actually improve the quality of the code found on such pages. We should document known security risks and publish "best practices" as part of the Drupal handbooks, but we should not limit the flexibility of the system. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher