discuss: TLDP Tech
Subject:
Re: TLDP Tech
From:
Rick Moen ####@####.####
Date:
6 Mar 2005 01:22:03 -0000
Message-Id: <20050306012201.GS27314@linuxmafia.com>
Quoting Emma Jane Hogbin ####@####.####
> So I would advocate going with PHP....but that's just me. It's plausible
> we end up with a multi-language environment with different components
> being hosted off-site and then "publishing" flat files to the ibiblio
> server.
I use PHP myself -- both by itself as a sort of HTML macro language and
in its very common role as an intermediary to SQL databases -- and find
it useful. (This post isn't advocacy for or against any
software-environment alternative; you just reminded me of something
relevant that should be taken into consideration, in my view.)
Early on with PHP, and to a large extent continuing to this day, the
emphasis has been on making the language and tools accessible to novices
as well as experienced users. Thus, a lot of good-programming
practices, especially for public-facing code, fell by the wayside, such
as requiring that variables be declared and scoped before use. In
consequence, the ability for anyone -- including random members of the
public -- to declare a global-scope variable at any time, hung over the
PHP-using community and lead to a number of security blowups in popular
PHP code over the last year or two. And that's not the only misfeature:
Here are three php.ini booleans I've set to "off", of late:
register_globals
allow_url_fopen
file_uploads
Each of those has traditionally defaulted to "on" as a convenience
feature, and each has been a security hazard. The register_globals one
was such a hazard that, after considerable dissention, they finally
changed it to default = off for newer versions.
Here's the thing, though: A lot of developed PHP code relies on that
behaviour. More than one PHP package -- bulletin board packages, wikis,
etc., breaks if, in the name of decent system security, you set that to
"off" -- and the installation instructions will typically say "This
package requires that you edit register_globals to "On".
What I'm mostly suggesting is that, although the language certainly does
support good, cautious coding, it also supports and (arguably) has for a
long time encouraged the opposite. And fixing badly coded PHP so that
it doesn't use security-risky shortcuts is much more difficult than
cranking it out was in the first place.
Just something to bear in mind.
