that all makes a lot of sense to me!
re,
tc
On Sat, Jul 28, 2001 at 10:17:42PM -0700, Rasmus Lerdorf wrote:
> The best thing about PHP is that it has such a shallow learning
> curve that
> non-programmers can write web apps.
>
> The worst thing about PHP is that it has such a shallow learning curve
> that non-programmers write web apps.
>
> That is of course oversimplifying things quite a bit, but it is the root
> of the issue here.
>
> The question is not whether we should do something about this, the
> question is what we should do about it. After reading all these messages
> and talking to people about it in person, here is what I see we need to
> achieve (not necessarily in order of importance):
>
> 1. A painless migration path for existing code
> 2. Minimal impact on the learning curve. I really don't like requiring
> neophyte users to have to understand associative arrays before they
> can get started with PHP.
> 3. Maximum protection for existing and new PHP apps
>
> How to get there...
>
> For 4.0.7:
>
> - We leave all default configuration settings as they are now.
> - We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
> super-globals like $GLOBALS
> - We add a new function, somewhat like the current extract() which looks
> something like this:
>
> // Import all Get/Post/Cookie variables in to the global(/current?)
> // namespace. Function could also be called import_symbols() or
> // register_globals() although the latter would be a bit confusing
> // since it doesn't take a boolean arg like the ini version.
> // If register_globals is on already this would be a no-op
> import_globals("GPC");
>
> // Another use:
> // Only import the given variables from Post or Cookie data.
> import_globals("PC",array('user','password','first','last'));
>
> // And perhaps some globbing:
> // Import any variable with abc in its name from anywhere.
> // Could alternatively use SQL-style or perhaps real regex
> // expressions here although I think full regex support would be
> // slightly overkill and perhaps too confusing for people.
> import_globals("GPCES","*abc*");
> - With the release of 4.0.7 we start hyping this security issue by
> linking to a spruced up version of the security chapter in the manual
> which describes how exactly to use these new tools.
> We could also provide a user-space implementation of the _$GET,
> $_POST... population logic and a user-space implementation of
> import_globals() so existing applications could check the PHP version
> and include our forward-compliance.inc file in order for their apps
> that conform to the new style to be backward compatible with older
> PHP installations. Or better, our .inc/.php file would do a version
> check for them.
> - We also start hyping that people who write and distribute PHP apps
> should strive to make their code E_NOTICE-clean.
>
> For 4.0.8:
>
> - If we didn't mess up in 4.0.7 and actually got something that works for
> people we consider turning on E_NOTICE by default and/or turning
> register_globals off by default.
>
> For 4.1:
> - I think a namespace approach might be interesting, although perhaps
> hard to get as granular as import_globals()
>
>
> Reasoning behind something like import_globals():
>
> Large existing web apps reference these GPECS variables everywhere. There
> may literally be thousands of lines of code to change and perhaps 10's of
> thousands of lines of code to check. Simply turning off register_globals
> would make these scripts fail invisibly. The end result will be that
> people just turn register_globals back on which may even be the documented
> requirement for these distributed apps. This doesn't help anybody.
>
> However, if the authors of these apps could make their code somewhat more
> secure by simply adding:
>
> import_globals("P");
>
> to their app-wide include file and assuming they only want POST variables
> imported, then they would probably do that. It isn't much of a security
> benefit at this level, but if they took it slightly further and checked
> their forms for form elements and pulled out the valid ones and specified
> these in an array we suddenly have a whole lot more security and instead
> of changing thousands of lines, they have added perhaps 5 or 6.
>
> And from a neophyte user perspective they don't need to understand
> associative arrays, they simply need to understand
> import_globals("GPC","form_*") which is much easier to teach. (assuming
> they named their form elements form_foo, form_bar, ...)
>
> Obviously the import_globals documentation should point people at the
> _GET[] direct access approach as well, although an import_globals() call
> with a precise list of valid variables should be even safer.
>
> -Rasmus
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
