Couldn't agree more with the message from oceanguy. I've only just developed my first live site with CakePHP. The live URL is allways running with debug level 0, so I am not at risk.
However, I do run a staging site, which can have the debug level set differently. I did not realise until this thread that there is a potential that this could lead to the staging site outputing the passwords for the database (again, only the passwords for staging. not live, but still not great) To be honest, its still not entirely clear when this would actually happen. It seems that it will be if there is an issue with connection to the DB, but again, no clear details on this. Thank you to the thread starter for alterting to this issue. I can understand why it is maybe not something the cakePHP team want to change, but I do think it needs to be made clear to developers that debug leves greater than 0 can expose passwords. On Jun 23, 6:03 am, euromark <[email protected]> wrote: > i always do it the other way around > in core debug=0 and if on localhost, raise it afterwards to 1/2 > this way there should be no flaws > > On 23 Jun., 06:50, oceanguy <[email protected]> wrote: > > > > > > > > > I've been baking for over 3 years, and while I know leaving debug >0 > > is not kosher, I often leave it temporarily at 1 for quasi-production > > sites, as it is a heck of a lot easier to debug run-time issues. > > > But I had no idea that database info would ever be exposed. And why > > would I? Seems like only a peculiar set of circumstances would have > > lead me to this error. If there's one piece of config information > > that shouldn't be exposed at all by an application, it's the db > > connection info. (Salt keys are probably a close second.) > > > If something is a bad practice, then it's up to the community to find > > the best way to inhibit it automatically. It's really a question of > > the community's integrity as a whole. If it's common for end user > > developers to make a mistake, then that speaks to an issue that needs > > to be addressed at the core level, otherwise everyone's reputation > > suffers. > > > CakePHP is a complex application and there is *a lot* to learn about > > it. Verbal notes hidden in forums (or even the docs) won't cut it, > > nor will saying, "if you followed best practice X, you wouldn't have > > exposed yourself to Y." End user developers do not know the details > > of how things might work under all circumstances, so we must trust the > > core developers to insure that best practices are in place to protect > > us from ourselves. > > > If it's a question of encouraging developers to maintain separate > > core.php files on dev and production machines, I think an alternative > > distribution model might be helpful. For example, maybe core.php > > should be distributed like database.php.default, which encourages devs > > to make a specific customized copy for each machine, which also > > implies not including it under version control. > > > Aside from this quibble, thanks for an awesome framework (and Mark, > > for a great blog). > > > -Sage > > > On Jun 22, 1:02 pm, mark_story <[email protected]> wrote: > > > > It is the developer's fault, for deploying a system in a way it should > > > never be deployed. > > > > Since, I was working under the pre-tense that any developer who > > > actually cared about these kinds of things wouldn't make a stupid > > > mistake like this. And combined with the fact that removing the > > > passwords is a non-trivial problem, I punted on the issue. The place > > > where this error gets displayed from is inside Debugger, and its more > > > than non-trivial to filter through the various parts of output, > > > looking for things that follow password, and cutting them out. While > > > this is probably doable it will affect all the messages that Debugger > > > will create. > > > > I guess I underestimated the ability of people to screw up basic > > > deployment. If someone want's to prepare a patch, I'd be happy to > > > apply it so people who can't be bothered to properly deploy their > > > applications, can sleep better at night. > > > > -Mark -- Our newest site for the community: CakePHP Video Tutorials http://tv.cakephp.org Check out the new CakePHP Questions site http://ask.cakephp.org and help others with their CakePHP related questions. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php
