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 <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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php
No comments:
Post a Comment