From: alex b. <en...@tu...> - 2001-05-14 01:35:43
|
actually, might as well ressurect this idea: a while ago, I considered adding another core class, called "vars" or something, which would be used this way: -turn off global variable registration for php. i.e. if you do: /index.php?foo=hello you _cannot_ access: $foo in a script. I can see everyone scratching their heads. The most secure wat to get input from the outside world is referencing: $HTTP_POST_VARS[var], $HTTP_GET_VARS[foo], etc PHP already has a means of determining the variable order, usually it's GPCS (get post cookie session). The problem with that is it can dump strange stuff into your environment that you don't necessarily know about. We would provide a similar means of ordering this stuff, but abstracted into a class so nothing would actually make it into the environment until it was requested. So, I thought it might be a good idea to make all "external" variable access pass through this single point, and in doing so, I could: -impose some checks on the input -make sure that _no_ user input would _ever_ be in the environment my code is running without my explicitly including that input via: $Var->getVar('foo'); or the like. I sort of liked that, it's a little inconvenient, but it's much more secure. Also, you could add some intelligence to getVar like: getVar('string', 'foo'), and getVar would check that the requested variable was a simple string (containing no - <? ?> or < > pairs, etc) that may be a bit overboard, but it would certainly be secure. thoughts? this is pretty easy to do, btw. and because of the way r2 pages are designed, we could just make it an option that loads only if a page explicitly requests it. (this can already be donw with auth, perm, and session - so unlike binarycloud r1, binarycloud r2 will be usable without a database, assuming you don't use modules or core components that require queries.) maybe I'll write that into the spec for core and mark it as "to do" see if anyone is interested in doing it. _alex |