Default bezpecnostne opatrenia – htaccess

Myslím Davide, že na to se Vláďa neptal…

David Grudl napsal(a):

Ten soubor tam je.

Valná většina malých a středních projektů používá nějaký základní hosting, kam nahrají Nette Sandbox, ve VirtualHostech (které nemohou měnit) je od poskytovatele nastavený adresář ten, kam nahráli Nette Sandbox a teď musí řešit, jak přesměrovat dotazy, které přijdou do podsložky www.

• DNS nepomůže, ta se nastavuje pouze na IP adresy ne na podsložky.
• VirtualHost nepomůže, jelikož tam má přístup pouze poskytovatel hostingu
• Poslední možnost (o které vím, případně mě doplň) je překopání .htaccess souboru co jsi poslal.

Tato poslední možnost znamená ale to, že ten soubor, na který odkazuješ je nutné předělat tak, že to co v něm je odstraníš a přidáš nové řádky, které veškeré dotazy do této složky přesměrují do složky /www

V tom případě se ale otevřela cesta i do ostatních složek, o kterých píše Vláďa. Takže ty .htaccess soubory jak Vláďa píše se tam musí přidat a je to strašně otravné. V minulých verzích sandboxu tam byly co vím. A upřímně taky nerozumím proč tam pořád nejsou.

Rozumím, že když si někdo pořídí VPSko, tak tam si to nastaví jak chce a nemusí toto řešit. Ale používat VPS za 1500/rok na projekt malého rázu, kam stačí hosting za 170/rok je asi jako vypustit přehradu abych z ní vytáhl 1 kapra…

Editoval Polki (5. 5. 2020 13:09)

@DavidGrudl To je dobrý nápad. Ovšem někdy má zákazník nějaký svůj hosting, který si platí a má jej předplacený na delší dobu a tedy jej měnit nechce. V takovém případě doporučení, které mi říká, že na tomto hostingu nemám Nette využívat, není relevantní, jelikož jej stejně budu muset využít.

Ještě jsem snad nenarazil na hosting, na kterém by nešlo jednoduše v administraci přepnout, jaká se používá verze PHP. Dnes snad už všechny podporují minimálně PHP 7.3.12, což měnit document_root u všech tak jednoduše, zdali vůbec, nejde.

(Možná to s tou adresářovou strukturou půjde nějak našolíchat, ale sám bych se toho bál a určitě to nebudu někomu radit.)

Kdo to teda radí například tady? A proč to vůbec vzniklo, když je to tak špatně?

Editoval Polki (5. 5. 2020 20:11)

@Polki teď nevím, kam se mě snažíš dotlačit. Pokud někdo používá špatný hosting, tak ho má změnit, jsou jich stovky a stojí pár korun. Pokud nechce, ok, ale proč by mě to mělo zajímat? Kdo to napsal do docky můžeš najít v git blame.

No, vadilo by něčemu mít to navíc i v těch defaultních adresářích?

WEDOS
ENDORA
atd.

Zakázáno ručně měnit httpd.conf je povětšinou z důvodů sdílení hardwaru mezi různými virtuálními stroji bezpečnostní záležitostí. Pokud to má nějakým způsobem hosting povoleno a vše ošetřeno, nevidím problém.

Citace z jakpsatweb : Server Apache se obvykle konfiguruje pomocí souboru httpd.conf. Tento soubor httpd.conf leží kdesi na serveru a má k němu přístup jenom administrátor serveru. To je organizačně náročné, proto vznikla možnost používat .htaccess.

Obecně pokud je server sdílený a běží na něm povícero hostingů, je nezodpovědné nechat měnit uživatele nastavení serveru. (Jistě, dnes již jsou způsoby jak vše izolovat, ale to je na jinou debatu.) .htaccess je tedy náhrada za httpd.conf, která umožní aplikovat nastavení v rámci daného adresáře. Jestli se tedy problém přesměrování do výchozího adresáře {DOCUMENT_ROOT}/www provede pomocí přenastavení document_root v httpd.conf, nebo přesměrováním všech přístupů v .htaccess je z mého pohledu úplně jedno.

Tím, že se explicitně Nette chová tak, že nepodporuje obě verze (proč očividně nikdo netuší) se Nette staví do pozice ‚použiji ho jen tam, kde mi to hosting dovolí‘.

Pokud nechce, ok, ale proč by mě to mělo zajímat?

Myslel jsem, že jsi chtěl, aby se Nette používalo a bylo populární. Obecně se setkávám s přístupem, že lidi, kteří své práci rozumí stejně jako ty do takových projektů nejdou. Firma si pak najde méně zkušeného člověka, který práci nějak slepí jak se dočte různě na fórech a když se pak firma rozroste a potřebuje v systému změny, na které nezkušený člověk nestačí a najme si firmu, tak se firma zhrozí nad takovým kódem a potom slýchávám, jak je Nette špatné, jelikož se v něm píšou věci špatně. To obecně není pravda. Jen za to mohou takováto rozhodnutí. Obecně tato rozhodnutí platí pro všechny jazyky/frameworky. Toto mě přivádí k otázce, zdali právě tento tvůj přístup Davide není ten důvod, proč se Nette nerozrostlo jak jsi čekal, jak říkáš v jednom svém rozhovoru pro mladypodnikatel.

teď nevím, kam se mě snažíš dotlačit.

Nikam :) Snažím se vést nějakou konstruktivní debatu. Neber prosím nic z toho co píšu jako útok. Všichni se můžeme plést. Je i dosti možné, že se i v této konverzaci já pletu. Jde jen o to najít tu cestu a znát všechny důvody proč ji zvolit a jestli je v pohodě tyto věci co jsem popsal v tomto komentáři tak nechat tedy jestli je v pohodě se ošidit o skupinu zákazníků, kteří využívají nedoporučené hostingy. (Například na wedosu běží spousta firemních webů a přijde mi škoda o takové množství uživatelů Nette přijít.)

Šaman napsal(a):

Protože když někdo neodborně upraví ten v rootu, může vzniknout bezpečnostní díra.

Bezpečnostní díra může vzniknout, když někdo neodborně upraví naprosto cokoliv.
A když někdo upraví ten v /app?
A když někdo upraví ten v /app/config?

Tohle může jít do nekonečna. Člověk bez odbornosti se vůbec v rootu nemá co „hrabat“.

Ano, ve starších verzích Nette byly tuším krom htaccessů i soubory pro IIS, zrovna tak by tam mohly být i pro Nginx…
Za implementaci odpovídá vývojář. Ani ten htaccess nemusí být na všech serverech stejný…

Nejrozumnější mi připadá jen v nápovědě nastínit best practice tipy.

@Felix

1. Nikde neni psano, ze nette/sandbox nebo nette/web-project se ma nahravat na server nebo pouzivat v produkci. Jestli to nekdo takto dela, neni to dobre.

Ještě jsem nepotkal nikoho, kdo by to dělal jinak. Myslím, že sandbox má vše, co potřebuješ aby si mohl rozjet Nette aplikaci. Zaváděcí soubor, konfigurační soubory, oddělenou aplikační logiku od veřejné části… prostě i kdybych si ručně doinstalovával composerem balíčky tak bych asi stejně napsal ty soubory, které jsou v sandboxu, čímž bych z toho ten sandbox vytvořil. Máš tedy nějaké dodatečné info, proč je to špatně?

2. Vnimam je jako projekty demonstrujici funkcnost Nette, ne webserveru. Pro minimalni vyvoj by mohl postacit PHP development server. Vsechno ostatni je bonus, ktery by mel ten, kdo to implementuje, vyresit.

Tomu moc nerozumím. Nainstaluju Development server, spustím composer create-project … a měl bych mít hotovo ne? Pak bych se měl starat o to, co mě baví, tedy o vývoj. Proto frameworky vznikají ne? Aby se nemusely pořád dokola dělat ty samé konfigurace dokola a dokola. Jasně chápu, že si každá firma upraví sandbox podle svých potřeb a používá svůj nový sandbox. Tak by to i mělo být podle mě. Nebo špatně tento bod chápu?

3. Neexistuje jenom Apache. Je rada i dalsich webserveru. To tam dame konfiguraci vsech?. Ikdyz je to mozna nejcastejsi volba u hostingu, tak porad, pred nasazenim, je nutne provest nejakou revizi.

Myslím, že není třeba dávat všechny. To by asi ani nedávalo smysl. Spíš bych koukl na nějaké analýzy a zjistil, jak si na tom jaký hosting stojí. Tedy kolik % používá Apache, kolik NGINX atd.. No a pak bych to viděl tak, že pro ty nejvíce používané by se udělaly zvlášť sandboxy se základní konfigurací, jako například composer create-project nette/web-project-apache a composer create-project nette/web-project-nginx no a pro ty ostatní které mají mizivé zastoupení by byla jak píšeš sekce v dokumentaci (ta by mohla být klidně s vychytávkami i pro ty, které budou mít sandbox).

Pokud jde o tvorbu té dokumentace, tak kdyby jsi do toho šel a chtěl pomoct tak napiš. Určitě bych nějak rád přispěl.

@kamil_v
od prvního kousku kódu v PHP, co jsem napsal, se vždy nastavoval development server tak, aby odpovídal produkčnímu serveru a to proto, aby to co se vyvíjí stačilo jen pushnout na server a vše běželo jak má. Učilo se to snad všude, kam jsem se podíval. Toto se značně zjednodušilo s nástupem dockeru.

Pokud jde o to, že někdy v budoucnu nebude hosting dostačující, nebo poskytovatel zkrachuje například, tak pak je to otázka přesunu. To by se ale nemělo myslím řešit při prvotním vývoji. Nehledě na to, že při přesunu z důvodů nedostatečného výkonu se většinou přesouvá aplikace na nějaké VPS, kde zase docker veškeré tyto problémy přenosu řeší ne?

Nebylo to tu explicitně řešeno tak jen doplním, že nastavení z .htaccess se automaticky dědí na podsložky a proto není technicky nutné ho do podložek kopírovat.