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
