Optimal solution to the problem AD7six. Good work. https://github.com/cakephp/cakephp/commit/e4fee14a5b1aca3c0af11549aa722358092853e7
I know it is the responsibility of the developer, but it is good to see that by the CakePHP core, developers are concerned and help create solutions. Thank you. On 23 jun, 02:03, euromark <dereurom...@googlemail.com> 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 <seagri...@gmail.com> 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 <mark.st...@gmail.com> 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 cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
