Re: Proposal

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: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net >