Úvodní strana - ošetření 404 na webserveru #269

New Issue

2018-07-31T19:18:54+02:00

Podhorecky commented

2018-07-31 19:18:54 +02:00

(Migrated from git.spotter.cz)

Neni to sice chyba, ale hlásim předem, prosím zkuste v ngnixu nebo kde nastavit že při 404 to pošle raději rovnou na homepage.

404 myslim nejspíš když se člověk omylem dostane někam kde nic neni nebo udělá překlep v psaní URL. Neni nutno vyrábět úchylnou 404ku :)
Případné jiné serverové chování dostupné pro uživatele z frontendu nechám na vás, může se postupně vylepšit.

Neni to sice chyba, ale hlásim předem, prosím zkuste v ngnixu nebo kde nastavit že při 404 to pošle raději rovnou na homepage. 404 myslim nejspíš když se člověk omylem dostane někam kde nic neni nebo udělá překlep v psaní URL. Neni nutno vyrábět úchylnou 404ku :) Případné jiné serverové chování dostupné pro uživatele z frontendu nechám na vás, může se postupně vylepšit.

Disassembler commented

2018-08-05 09:13:05 +02:00

(Migrated from git.spotter.cz)

Ha! To je zrovna problém, který se na první pohled zdá jako strašná prkotina, ale ve skutečnosti je dost komplexní. Záleží totiž kde se uklepne.

1. Pokud se někdo uklepne v názvu domény, záleží na tom, zde je celá nadřazená doména nasměrovaná na server nebo ne.
- 1.1. Pokud ano, nejprve uživatel uvidí bezpečnostní upozornění, protože pro neexistující subdoménu nebude existovat certifikát. V případě, že jej potvrdí, jeho požadavek bude přijat výchozím hostitelem, do kterého automaticky padají i požadavky pro neznámé názvy.
  - 1.1.1. Pokud v URL není žádný kontext (nic za lomítkem) nebo je v kontextu URL, která je v rámci aplikace portálu platná, zobrazí se stránka s portálem a ke 404 nedojde.
  - 1.1.2. Pokud v URL je kontext, který není platný v aplikaci portálu, zobrazí se 404 emitovaná hlavní instancí nginxu.
- 1.2. Pokud nasměrovaná není, dostane se buď na jiný server nebo vůbec nikam, v závislosti na nastavení DNS. To nijak ovlivnit nemůžeme, protože to jde úplně mimo VM.
1. Pokud se někdo uklepne v kontextu (za lomítkem), záleží na subdoméně ve které se tak stalo
- 2.1. Pokud se uklepl v kontextu přímo v subdoméně aplikace portálu, pak platí 1.1.2.
- 2.2. Pokud se uklepl v kontextu v subdoméně jiné aplikace, pak je chyba zpracována a emitována serverem dané aplikace ve svém aplikačním kontejneru do kterého hlavní instance nginxu transparentně posílá všechny požadavky. Pak závisí na tom, jaký software je v něm použit pro obsluhu spojení a zda si aplikace sama obsluhuje chybové stránky.
  - 2.2.1. Spojení je obsluhováno jakkoliv a aplikace chyby řeší = Zobrazí se krásná barevná chybová stránka dané aplikace.
  - 2.2.2. Spojení obsluhuje nginx a aplikace chyby neřeší = Zobrazí se holá 404. Možno obsloužit stejným způsobem jako 1.1.2, ale je nutno stejné řešení opakovat v každém takovém kontejneru.
  - 2.2.3. Spojení neobsluhuje nginx a aplikace chyby neřeší = Nutno řešit individuálně pro každý software obsluhující spojení. Tomcat nějakou obsluhu chyb umožňuje, Node.js, ruby a pythonovské frameworky by vyžadovaly zásah do kódu. Je možno na hlavní instanci nginxu udělat nějaké catch-all pravidlo, ale tím se přepíšou i obsluhované chyby z 2.2.1.
1. Přímý redirect na hlavní stranu navíc nedoporučuji, protože v případě, že takovou stranu navštíví robot nebo nějaké programové rozhraní, potřebuje vědět, že tam nic není, k čemuž právě slouží onen kód 404. Takže místo přímého redirectu bych spíše preferoval, aby na stránce byl nějaký stručný text o tom, že tudy cesta nevede a může tam být klikatelný odkaz vedoucí na hlavní stranu dané aplikace na který si už uživatel bude muset kliknout sám.

Každopádně se nad tím zamyslím a zkusím vyřešit alespoň pro ty úplně holé 404.

P.S.: V případě, že je kontejner chcíplý, hlavní nginx teď místo strohého "502 Bad gateway" vypíše "Aplikace ke které se pokoušíte připojit není dostupná. Nejspíše byla vypnuta správcem serveru.", nicméně tam to ošetření bylo daleko jednodušší, protože no není potřeba řešit uvnitř kontejnerů.

Ha! To je zrovna problém, který se na první pohled zdá jako strašná prkotina, ale ve skutečnosti je dost komplexní. Záleží totiž *kde* se uklepne. - 1. Pokud se někdo uklepne v názvu domény, záleží na tom, zde je celá nadřazená doména nasměrovaná na server nebo ne. - 1.1. Pokud ano, nejprve uživatel uvidí bezpečnostní upozornění, protože pro neexistující subdoménu nebude existovat certifikát. V případě, že jej potvrdí, jeho požadavek bude přijat výchozím hostitelem, do kterého automaticky padají i požadavky pro neznámé názvy. - 1.1.1. Pokud v URL není žádný kontext (nic za lomítkem) nebo je v kontextu URL, která je v rámci aplikace portálu platná, zobrazí se stránka s portálem a ke 404 nedojde. - 1.1.2. Pokud v URL je kontext, který není platný v aplikaci portálu, zobrazí se 404 emitovaná hlavní instancí nginxu. - 1.2. Pokud nasměrovaná není, dostane se buď na jiný server nebo vůbec nikam, v závislosti na nastavení DNS. To nijak ovlivnit nemůžeme, protože to jde úplně mimo VM. - 2. Pokud se někdo uklepne v kontextu (za lomítkem), záleží na subdoméně ve které se tak stalo - 2.1. Pokud se uklepl v kontextu přímo v subdoméně aplikace portálu, pak platí 1.1.2. - 2.2. Pokud se uklepl v kontextu v subdoméně jiné aplikace, pak je chyba zpracována a emitována serverem dané aplikace ve svém aplikačním kontejneru do kterého hlavní instance nginxu transparentně posílá všechny požadavky. Pak závisí na tom, jaký software je v něm použit pro obsluhu spojení a zda si aplikace sama obsluhuje chybové stránky. - 2.2.1. Spojení je obsluhováno jakkoliv a aplikace chyby řeší = Zobrazí se krásná barevná chybová stránka dané aplikace. - 2.2.2. Spojení obsluhuje nginx a aplikace chyby neřeší = Zobrazí se holá 404. Možno obsloužit stejným způsobem jako 1.1.2, ale je nutno stejné řešení opakovat v každém takovém kontejneru. - 2.2.3. Spojení neobsluhuje nginx a aplikace chyby neřeší = Nutno řešit individuálně pro každý software obsluhující spojení. Tomcat nějakou obsluhu chyb umožňuje, Node.js, ruby a pythonovské frameworky by vyžadovaly zásah do kódu. Je možno na hlavní instanci nginxu udělat nějaké catch-all pravidlo, ale tím se přepíšou i obsluhované chyby z 2.2.1. - 3. Přímý redirect na hlavní stranu navíc nedoporučuji, protože v případě, že takovou stranu navštíví robot nebo nějaké programové rozhraní, potřebuje vědět, že tam nic není, k čemuž právě slouží onen kód 404. Takže místo přímého redirectu bych spíše preferoval, aby na stránce byl nějaký stručný text o tom, že tudy cesta nevede a může tam být klikatelný odkaz vedoucí na hlavní stranu dané aplikace na který si už uživatel bude muset kliknout sám. Každopádně se nad tím zamyslím a zkusím vyřešit alespoň pro ty úplně holé 404. P.S.: V případě, že je kontejner chcíplý, hlavní nginx teď místo strohého "*502 Bad gateway*" vypíše "*Aplikace ke které se pokoušíte připojit není dostupná. Nejspíše byla vypnuta správcem serveru.*", nicméně tam to ošetření bylo daleko jednodušší, protože no není potřeba řešit uvnitř kontejnerů.

Podhorecky commented

2018-08-05 09:29:52 +02:00

(Migrated from git.spotter.cz)

a safra... díky za rozbor. Původně jsem nemyslel, že by to platilo na všechny apps ve VM. Myslel jsem to jen v případě vašeho SW. Nicméně, pokud vás něco minimalistického napadne, tak ok. Nemusíte tomu věnovat příliš energie. Tj. pokud by hrozilo že bude příliš jebání a málo muziky, tak to prozatím odložte.

Disassembler commented

2018-08-14 15:11:02 +02:00

(Migrated from git.spotter.cz)

mentioned in commit 86e411df12

mentioned in commit 86e411df122cab33b36a6d1337c74492576dcccd

Disassembler commented

2018-08-14 15:15:25 +02:00

(Migrated from git.spotter.cz)

Vlastní 404 do management aplikace přidána. Ostatní budeme řešit individuálně, nastane-li potřeba. Dá se to řešit jak na straně aplikace, tak i tím catch-all pravidlem na nginx proxy (kdybych to do té doby zapomněl, tak to se dělá pomocí proxy_intercept_errors).

Vlastní 404 do management aplikace přidána. Ostatní budeme řešit individuálně, nastane-li potřeba. Dá se to řešit jak na straně aplikace, tak i tím catch-all pravidlem na nginx proxy (kdybych to do té doby zapomněl, tak to se dělá pomocí [proxy_intercept_errors](http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors)).

Disassembler commented

2018-08-14 15:15:25 +02:00

(Migrated from git.spotter.cz)

closed

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Spotter-Cluster/Spotter-VM#269