[development] Remove PHP filter by default

Syscrusher scott at 4th.com
Sun Jan 29 16:12:29 UTC 2006


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


More information about the development mailing list