Get rid of Environment autodetection

wdolek

Auto detection of Environment is fine until:

user (programmer) knows what it exactly means for him
admins don't change settings of server

There are cases when user has server configured with error_reporting = 0 but Nette\Debug (in older releases) decides that web is running on localhost, so it override this setting. Ok, this should be problem of admins, who doesn't follow RFC (using local IP ranges for public server), but still, it is quite dangerous anyway – no matter who caused such situation.

We had discussion about this on #posob (Last Saturday meeting) – my idea was rejected because this is influencing only small amount of users, or that it is really nice feature to have and no one wanted to remove it.

IMHO it is fine for newbies, but also really dangerous – this feature is not documented properly, also there is (was?) mix with Environment / Debugger setup.

Therefore I'm proposing two solutions how to get rid of auto-detect and make user (programmer) choice on him itself.

Similar to Symfony, use index.php and index_dev.php. On localhost (or any dev machine), programmer can reach index_dev.php – there is nothing more clearer than this, without any magic inside.
Provide value to PHP that script is running in development environment.

# .htaccess
SetEnv NETTE_ENVIRONMENT = "DEVEL"

// enable debugging, Ladenka, etc.
if (isset($_SERVER['NETTE_ENVIRONMENT']) && ($_SERVER['NETTE_ENVIRONMENT'] == 'DEVEL')) {
    ...
}
// else be quiet!

For both proposals, default settings of Nette would be to disable Nette\Debug or any thing, which could send anything to stdout!
Second idea is related to Apache, I'm not sure, if this is possible with every http server.

Last edited by wdolek (2011-11-28 12:59)

paranoiq

related: https://github.com/…e/issues/401

HosipLan

The good thing is, that all this is placed in sandbox and can be changed without rewriting framework code :)

Just fork https://github.com/nette/sandbox and make your changes :)

wdolek

HosipLan wrote:

The good thing is, that all this is placed in sandbox and can be changed without rewriting framework code :)

But it would solve only sandbox and not Framework magic decisions… Do we want safe framework (look at forms), or framework, which is kinda smart, but may cause such critical failure in securing source codes of app?

HosipLan

Autodetection is good default behaviour, but you can override it :)

if (isset($_SERVER['NETTE_ENVIRONMENT']) && ($_SERVER['NETTE_ENVIRONMENT'] == 'DEVEL')) {
	Debugger::enable(Debugger::PRODUCTION);
	// ...

} else {
	// ...
}

I see no problem here. Do you?

wdolek

HosipLan wrote:

but you can override it

you can – isn't that cute? But it's WRONG! Nette should stay as quiet as it is possible – enabling of sending stuff to stdout (source codes, environment settings) should always require user's action. Enabling it “magically” on decision of framework is dangerous. This is not matter of sandbox' bootstrap at all.

HosipLan

I guess, some warning in documentation would be a good idea for start :)

But why it wasn't problem until now? Personally, I've never had problem with this on localhost+standard hosting solutions, and as you've said, it's good for beginers, that don't do intranets for banks.

Convention over configuration?

wdolek

HosipLan wrote:
But why it wasn't problem until now?

Nobody cared? Nobody saw few live web apps with Nette\Debug(ger) on?

Honza Kuchař

wdolek wrote:

HosipLan wrote:

but you can override it

you can – isn't that cute? But it's WRONG! Nette should stay as quiet as it is possible – enabling of sending stuff to stdout (source codes, environment settings) should always require user's action. Enabling it “magically” on decision of framework is dangerous. This is not matter of sandbox' bootstrap at all.

I absolutely agree! I also overwrite auto-detection code in every my project. I created file in app directory, called debug.mode and inside of this file is name of mode (practicaly section in config) which will be used.

Last edited by Honza Kuchař (2012-01-14 12:54)

David Grudl

This is already solved, I hope.