Nette by měl generovat warning, když bude config přístupný z URL

+1 (myslel jsem, že je to tak logické)

Udej příklad prostředí, kde to vygeneruje špatně URL. To, co ještě není implementované. Takže samozřejmě už dopředu víme, kde to nebude fungovat, žejo ;)

Nemusí se to nijak drasticky hlásit, ale pokud to zachrání aspoň jeden web, tak to smysl má. Nebyl jsi to ty, kdo před pár dny psal na github pod signály, že aspoň nějaké zabezpečení, než žádné?

Editoval HosipLan (29. 3. 2012 21:54)

-1, z důvodu, který uvedl hrach. Vymyslet si URL a tu pak testovat, to dává falešný pocit bezpečí (např. si ji vymyslí blbě nebo kontrolu vůbec nebude moci provést) a zároveň to může potenciálně způsobovat problémy (je to HTTP request jako každý jiný, který je položen na neznámou URL).

Dva jednoduché scénáře k zamyšlení:
a)

/app/config/config.neon
/www/index.php

Co když aplikace poběží ve špatném prostředí (= standardní hosting) kde složka = subdoména? Pak (hypoteticky) může být URL http://app.example.com/config/config.neon, ale jak by to Nette zjistilo?

b)

/app/config/config.neon
/index.php

Tohle řešení použil už kdekdo, právě kvůli hostingům, aby neměl app jako subdoménu. Nicméně, každá aplikace nějak nakládá s neexisující URL. Tady by URL byla: http://example.com/app/config/config.neon. A co teď? Na té URL bude vždy něco existovat (každá Nette aplikace reaguje na neplatný request) a vrátí buď 404 nebo klidně i dokonce 200 (resp. na status kód se nelze spolehnout). Zároveň se ale, za předpokladu, že se na té URL opravdu jedná o config.neon, nelze spolehnout ani na obsah souboru (co když bude např. prázdný?). Z toho tak trochu vyplývá, že i když ta URL existuje, nedá se vlastně snadno určit, jestli to config.neon je nebo ne.

raději bych přidal přesměrování přípony .neon (a .ini) do nastavení url rewriteru v příkladech a skeletonu

$i--;
Každý request sám o sobě představuje určitou zátěž. Pokud bys to chtěl udělat neprůstřelné, znamenalo by to každý request prodloužit o ten tvůj bezpečnostní subrequest.

@**paranoiq**: v app je ve skeletonu .htaccess, který zabraňuje aby složka byla přístupná. Tohle by tedy bezpečnosti nepřidalo.

Tyhle průsery vznikají tak, že programátor nenahraje .htaccess na server, nebo server neběží na apachi/iis.

Problém by se dal řešit ještě tak, že pokud bude app složka v document rootu, nette bude kontrolovat jestli je htaccess ve správné složce (v app) a jestli současné prostředí ho neignoruje. Nginx na něj totiž rozhodně kašle.

Tohle by Nette asi řešit neměl. Je to zbytečná režie navíc.

tomhrb napsal(a):

trosku se vratim k tomuto vlaknu, ponevadz to nyni resim. jako blbuvzdorne reseni se mi jevi, kdyby neon.config povolil syntaxi s <?php na zacatku souboru. to by pak pristup k takovemu souboru (jmenoval-li by se neon.config.php) vypsalo prazdno. pokud neco takoveho jiz nette umi, vi nekdo prosim, jak prenastavit configurator aby ignoroval tyto uvodni znaky (tedy <?php)?
dekuji

Můžeš použít Neon komentář:

# <?php die(); ?>
common:
	parameters:
		atd: ...

Jenže config loader u přípony PHP očekává PHP, konfiguráky se totiž dají psát i v čistém PHP. Tohle se nedá změnit úplně snadno. Nejjednodušeji asi poděděním Configuratoru, předefinováním createLoader() a přepsáním private property $adapters. Je to trochu špína, ale mělo by to fungovat:

	/**
	 * @return Loader
	 */
	protected function createLoader()
	{
		$loader = new Loader;
		$loader->reflection->properties['adapters']->setAccessible(TRUE);
		$loader->reflection->properties['adapters']->setValue($loader, array('php' => 'Nette\Config\Adapters\NeonAdapter'));
		return $loader;
	}