Route::SECURED nevynucuje HTTPS 100%
- _Martin_
- Generous Backer | 679
Ahoj,
všiml jsem si, že v některých přístupech Nette povolí přístup přes
HTTP protokol, ačkoliv má routa nastaven příznak
Route::SECURED. V dokumentaci o tom zmínka není, takže nevím,
zda jde o cílené chování nebo o chybu. K druhé variantě se
kloním víc.
K situaci dojde, pokud z presenteru odešlu jinou odpověď než
standardně přes šablonu. Tj. například při použití
TextResponse nebo při klasickém echování a příkazu
$this->terminate(). Nezkoumal jsem chování pro
FileResponse a další, ale hádám, že se to bude chovat
obdobně.
- _Martin_
- Generous Backer | 679
Co přesně je feature? Že funkce, která má vynucovat HTTPS nevynucuje HTTPS? Viz dokumentace:
U routy lze vynutit používání zabezpečeného protokolu HTTPS uvedením příznaku SECURED.
Nevím, zda mluvíš za tým kolem Nette. Jestli v okruhu Nette vývojářů padlo rozhodnutí, že takovou věc má dělat server a ne framework, tak by ale tahle funkcionalita a tenhle kus dokumentace měly zmizet, jinak uvádějí všechny uživatele frameworku do mylné představy, že jejich aplikace je chráněná pomocí HTTPS.
A pokud takové rozhodnutí nepadlo, pak by ta funkce měla fungovat 100% a k tomuto zjištění by se mělo přistoupit jako k bugreportu. A pokud by bylo nesmírně složité fungování opravit, tak alespoň upozornit v dokumentaci, že pro určité typy odpovědí HTTPS nevynucuje.
- Jan Tvrdík
- Nette guru | 2595
Co přesně je feature?
Současná chování. Spojení „to je feature“ znamená, že to chování nevniklo omylem a nejedná se o chybu. Naopak jde o zcela záměrné chování.
Jestli v okruhu Nette vývojářů padlo rozhodnutí, že takovou věc má dělat server a ne framework
To rozhodnutí padlo před více než 7 lety, kdy to David implementoval.
Viz dokumentace
Dokumentaci můžeš opravit.
- David Grudl
- Nette Core | 8215
Flag SECURED jen říká, jaké URL má router generovat, se zabráněním přístupu přes HTTP to nesouvisí. Máš pravdu, že dokumentace to neříká jasně, a bude super, pokud pošleš opravu na https://github.com/nette/docs
- _Martin_
- Generous Backer | 679
Davide, a nebylo by lepší, aby to ta funkce uměla? Zatím jsem blíže nezkoumal zdrojáky, ale přišlo by mi to fajn, když už to ta funkce částečně umí. V každém případě doporučuji upozornit ostatní vývojáře, protože nejspíš nebudu jediný, kdo kvůli té zmínce v dokumentaci věří, že se k žádným datům v jeho aplikaci nedá bez HTTPS dostat. To zavání zásadní bezpečnostní chybou.
Honzo, trochu mě mrzí tvůj arogantní přístup. Pamatuji si fórum mnohem vstřícnější.
Editoval _Martin_ (20. 5. 2016 11:25)
- Jan Tvrdík
- Nette guru | 2595
a nebylo by lepší, aby to ta funkce uměla?
Nemyslím si, výchozí protokol na internetu je HTTP. Je prakticky
nezbytné, aby web běžící na HTTPS dokázal přesměrovat požadavky, které
přijdou přes protokol HTTP, protože normální uživatelé nikdy
https:// do adresního řádku psát nebudou. Správné řešení
je přesměrovat na úrovni serveru. Pokud je server chybně nastavený, tak
Nette jako nouzové řešení to přesměrování taky vynutí.
Diskutovat můžeme leda tak o tom, že by přes HTTP akceptoval pouze metodu GET, ale jsem dost přesvědčený, že ani takovou změnu nepůjde udělat kvůli BC, neboť někdo určité spoléhá na funkčnost nějakých starých formulářů, co se odesílají ještě přes HTTP.
kvůli té zmínce v dokumentaci věří, že se k žádným datům v jeho aplikaci nedá bez HTTPS dostat.
Pokud máš špatně nastavený server, tak minimálně ke všem statickým datům se půjde dostat, ať už Nette udělá cokoliv.
Honzo, trochu mě mrzí tvůj arogantní přístup.
Arogance je jeden z konceptů společnosti, který nechápu, omlouvám se.
- Milo
- Nette Core | 1283
@_Martin_ Odkud tu response posíláš? Z action nebo z
render? Tipuji, že z action. IMHO bys měl v render,
tam se mají vykreslovat data na výstup.
EDIT: Ptám se proto, protože SECURED je aplikováno při
kanonizaci URL a kanonizace se
provádí po action, ale před render.
Data by se tak měly vypisovat (šablona, response) až v render, jinak je
kanonizace k ničemu. Z mého pohledu je to správně. Například pro HEAD
metodu se volá jen action, kde si mohu nastavit HTTP hlavičky,
ale render už ne, protože HEAD nemá tělo.
PS: Do dalších verzí Nette bych se SECURED stejně radši moc
nepočítal :)
- David Grudl
- Nette Core | 8215
_Martin_ napsal(a):
Davide, a nebylo by lepší, aby to ta funkce uměla?
Router samotný není místem, kde by se měl blokovat přístup. Ten může pouze URL neakceptovat, což by ale způsobilo dost kolosální BC break. Přístup může odmítnout Presenter, ale aby mohl respektovat flag na routě, musel by vědět, jak byl naroutován a to taky není košer. Presenter nicméně dělá kanonalizaci URL, v důsledku čehož k přesměrování dojde, ale na tohle není úplně záhodno spoléhat (viz tvůj issue, navíc k ní nedochází při POST nebo AJAX požadavku). Navíc je to docela drahé přesměrování, sestaví se celá aplikace, než se zjistí, že se má přesměrovat.
Tím pravým místem je skutečně nastavení serveru. Protože
- chceš přesměrovávat veškerý traffic, nikoliv jen ten, co jde na presentery
- chceš veškerý traffic mít na HTTPS (předpokládám)
V každém případě doporučuji upozornit ostatní vývojáře, protože nejspíš nebudu jediný, kdo kvůli té zmínce v dokumentaci věří, že se k žádným datům v jeho aplikaci nedá bez HTTPS dostat.
Budu fakt rád, když to do dokumentace přidáš.
Honzo, trochu mě mrzí tvůj arogantní přístup. Pamatuji si fórum mnohem vstřícnější.
Jo, tohle mě taky štve.
