Hacker News Reader

Comment by Areading314 | Hacker News Reader

This is a great concrete example why you should never run debug mode on a public server. Django can only do so much for redacting private info. This is also a great example of how insecure pickle is!

View on HN

Luckily, Django provides checks to avoid this kind of leakage before hitting production with https://docs.djangoproject.com/en/2.1/howto/deployment/check...

And to be fair, the docs are littered with warnings about not using debug mode in production. Debug mode is open for.... debugging. not production.

wow thanks - just ran this on some production servers and caught some intersting stuff! had no clue this command existed.

They were running django 1.6 ....

Sentry still requires 1.6:

https://github.com/getsentry/sentry/blob/ea8fe10d117f5325f9e...

I know this is going to get some jeering, but that's one nice thing about .Net's machine.config <deployment retail="true" />, you designate the machine itself as a non-development environment and tracing, debug output, and so on are disabled for all .Net/ASP.Net applications.

That might not work for all edge cases, but broadly there's a lot of machines which are only for non-development/production code, and a system-wide setting makes you a lot safer.

Funnily enough, it is mostly .NET applications running in production that I see stack-traces from these days.

If you even know something is a .Net app then the developer is likely terrible, so it is a self-selecting sample. You don't know most of the .Net MVC apps you interact with because there's no reason to know that.

Boy, getting hammered for poor phrasing. What's meant is if the stack (whatever it is) bleeds into the user experience, the dev has done a poor job.

This is really discriminatory and arrogant.

I used to feel the same way. It’s worth changing.

I think they mean if you can tell that it's a .NET app (e.g. because they left the X-Powered-By header on), not if it's a .NET app in general.

Facepalm. I've filled my dumb comment quota for the week.

Well, at least it was clarified. It got a couple upvotes, so I guess others misinterpreted it too. Sorry.

That's true for basically every stack

> If you even know something is a .Net app then the developer is likely terrible

For sake of argument, this is pretty easy to do just by looking at job postings.

Ever heard of Jon Skeet?

You can use env vars to do similarly for all the big frameworks (django, rails, etc)

Just a thought. This might actually be trivial to implement in a unix environment from the administration side of things. I'm not 100% sure but all child processes inherit the env vars from the parent correct? So setting `environment=production` high up in the process tree should make it available to all processes.

There's still chances of this getting overridden down the line and all apps have to conform to one style but at least it's possible?

Absolutely. But none of the major players are looking for it, and they all have unique ways of designating the machine that way.

There's no specific technological challenges, this is entirely political, getting half a dozen or more different projects with different priorities to check the same variable for the same purpose.

Plenty of production apps in my line of work are executed with `env -i` for consistency.

I don't know what the standard way is to deploy django or .net apps, but nodejs apps are often packaged into a docker container, or cloud function, that run independently, not on any particular machine that you designate as 'production'. So 'system-wide' settings don't really exist because there is no concept of a machine.

With nodejs in a docker contianer for example you specify whether the server is designated for production or not during build time, not when you run it.

I think you're a little over-confident in the Node community; I've seen a lot of Node apps deployed the same as any other (just tar'ed up and deployed via some kind of script or other deployment tool).

Seems a bit of the HN echo chamber; people here seem to think, because of the high quality stories and comments, that the entire world uses best practices for everything; containers, code reviews, versioning, test coverage, CI, automated deployments, etc. While in reality I think most places are not doing that. This is anecdotal ofcourse but most (large and small) companies I have worked with (as clients or partners) are in fact doing none of these things.

Quite true. I hardly see any of the best practices that keep being discussed here.

Small to middle size companies whose main business is totally unrelated to selling software just care that their stuff works somehow. And everything that IT does is a cost center.

I guess that's .NET Framework only - is there something similar for .NET Core?

Exactly.. i think you often see a warning about pickle when it comes to safety. For example, the current documentation has a big, red warning right at the top: https://docs.python.org/3/library/pickle.html

The Django project also has a lot of warnings about the pickle serializer: https://docs.djangoproject.com/en/2.1/topics/http/sessions/

I think maybe frameworks should stop calling it debug mode and start calling it "danger mode". Because clearly people aren't paying attention to what it actually does.

Reply on news.ycombinator.com