From: Thijs K. <ki...@sq...> - 2007-07-16 07:14:20
|
On Sunday 15 July 2007 21:37, Paul Lesniewski wrote: > On 7/15/07, Chris Hilts <ta...@sq...> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Thijs Kinkhorst wrote: > > > I'd be more in favour of something like 'config_local.php' that we > > > already have. If we can make sure that this file is always included > > > after the loading of the regular configuration, we can make it the > > > recommended way to override settings through PHP code. > > > > I sort of thought it already was. That was the design idea when it was > > added, anyway.. Indeed, I meant s/make it/keep it/. > Heh, well, you haven't read the rest of this thread, then. ;-) It > might very well go away. > > Thijs, the PHP is NOT coming from end users, so this concern does NOT > fall in the class of needing to worry heavily about sanitizing stuff > from the wild. There difference in user manipulated settings and admin manipulated setting= s=20 is getting a lot smaller in the new system, since both are essentially=20 treated the same way. I'm therefore wary that the code that needs to check= =20 whether you're allowed to enter PHP code in some field may turn out not to = be=20 so completely watertight as we intended. And how do you handle escaping? If someone enters something that starts=20 with "$", is he meaning to use e.g. a Webmail Title with a dollar sign, or= =20 does he want to use PHP code? How do you handle the case where someone wants to use a few lines of PHP co= de =20 in a setting and the box is only a textfield of width 40 chars? To me it opens up quite some problems to allow it in arbitrarily any settin= g.=20 If you put it into config_local, there's one canonical place to override=20 settings through code, with no security risks, with full freedom of=20 expression, and it's already there. Thijs |