My dos centimos: This certainly isn't a bug. It's a "marmite" featured insofar as you either like it or you don't.
This happened to me once on a dev site that somehow got cached by Google. It was a shock, but it also gave me a slap on the wrists and I was lucky - Lesson: never push anything public unless debug is 0. I personally don't agree with sensitive information like passwords appearing in debug - but I can live with it if I am aware it can happen. As the trace is generally collapsed, it can be difficult to spot any highly sensitive information is public for the more naive developer. I think a warning (prominent) in the docs that this can happen would suffice. In this case, if you don't read the manual, you have no one else to blame. On Jun 23, 7: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
