Dajbych.net

Několik poznámek k sonaru

, 6 minut čtení

sonar logo

Validátor je skvělý nástroj, který kontroluje váš web na neviditelné vady. Je jich mnoho, ale Sonar se liší od všech ostatních. Je to jediný testovací nástroj, jehož cílem je komplexně ověřovat webové stránky, je open source a řízen komunitou a má integraci prohlížeče. Proč vývojáři frontendu potřebují komplexní testovací nástroj? Proč je důležitá nezávislost na jakémkoli velkém dodavateli softwaru? A nakonec – má Sonar potenciál a je nyní užitečným nástrojem? No, shromáždil jsem několik významných poznámek o jeho kvalitě.

K čemu jsou validátory dobré?

V oblasti vývoje webových aplikací se pohybuji již více než 17 let. Rád sleduji, jak se World Wide Web mění v průběhu času. Některé moderní přístupy se standardizují, zatímco jiné upadají v zapomnění. Setkal jsem se s velmi dobrými (HTML5 od Iana Hicksona), velmi špatnými (RSS od Dave Winera) a velmi kontroverzními (CSS Level 1 od W3 Consortium) specifikacemi. Někdy je špatná specifikace, jindy je nesprávná implementace. Validátory jsou užitečné v procesu maximalizace kompatibility webu, ale mohou vás také učinit 100% kompatibilními s jednou softwarovou společností za cenu porušení kompatibility s desítkami dalších společností. V zásadě existují dvě možnosti. Za prvé, použijte co nejvíce validátorů a iterujte, abyste minimalizovali počet chyb, nebo za druhé, použijte jeden univerzální validátor nezávislý na dodavateli, který zná nejlepší možné techniky pro vás.

V současné době používám tyto validátory:

Podívejme se na sonar

Ustanovení sonar i modern.IE jsou vytvořena vývojovým týmem prohlížeče IE/Edge. Proč byla ukončena podpora modern.IE a proč sonar nezahrnuje ověření konfiguračního schématu prohlížeče?

Nemyslím si, že webová stránka obsluhovaná s hlavičkou HTTP Content-Type: application/xhtml+xml musí obsahovat parametr znakové sady HTTP, protože kódování dokumentu XML je ve výchozím nastavení UTF-8.

Souhlasím s tím, že styl CSS obsluhovaný s hlavičkou HTTP Content-Type: text/css by měl mít parametr charset=utf-8, ale proč to není opraveno již v ASP.NET Core 2?

Doporučení ohledně režimů dokumentů IE je velmi vtipné. Za prvé, pokud je stránka zobrazena jako application/xhtml+xml, IE 9 a novější použije analyzátor XML a vynutí režim nejvyšších dostupných standardů. Za druhé, i když pošlu typ obsahu jako text/html, opravdu nepotřebuji používat záhlaví nebo meta tag X-UA-Compatible, abych se vyhnul režimu kompatibility, protože pokud stránka obsahuje typ dokumentu HTML5, IE 6 a novější automaticky použije režim nejvyšších dostupných standardů (v případě IE 6 pouze v případě, že je vynechán prolog XML). Sonar by to měl nejprve zkontrolovat, než začne šířit alarmové zprávy.

Zajímavé je, že během Microsoft Edge Web Summitu byl doporučený typ obsahu pro soubory ECMAScript application/javascript a nyní je doporučený typ obsahu text/javascript. Nicméně RFC 4329 z roku 2006 doporučuje application/javascript. Sonar by měl alespoň zaznamenat, které prohlížeče stále nejsou kompatibilní s tímto standardem. Mimochodem, ASP.NET Core 2 poskytuje soubory s příponou .js jako application/javascript.

Nemyslím si, že HTTP hlavička X-Content-Type-Options musí být specifikována, když server odesílá statické soubory, které nejsou generovány uživatelem.

Nemyslím si, že HTTP hlavička Strict-Transport-Security musí být specifikována, když server posílá styly, skripty nebo obrázky. Server přesměruje uživatele z HTTP na HTTP+TLS a při prvním požadavku nastaví hlavičku HSTS. Styly, skripty a obrázky se stáhnou později, takže hlavička HSTS již nebude platit. Situace je odlišná, pokud jsou tyto prostředky načteny z jiné domény. Sonar by měl tyto dva případy rozlišovat a zobrazit chybu pouze v případě, že se doména liší.

Proč by soubory CSS nebo ECMAScript měly mít parametr charset=utf-8 v záhlaví Content-Type? Předpokládejme, že agent ignoruje BOM nebo že server má soubor s kódováním UTF-8 bez BOM. Jedná se o problém pouze v případě, že soubor obsahuje jiné znaky než ASCII. Sonar by to měl vzít v úvahu.

Sonar nezobrazí upozornění, pokud web používá kompresi obsahu na šifrovaném připojení, pokud není použito kódování blokového přenosu. Tyto 3 podmínky činí web zranitelným vůči útoku BREACH .

Souhlasím s tím, že hlavičky Server a X-Powered-By jsou zbytečné a mohly by představovat bezpečnostní riziko, ale proč jsou webové aplikace Azure nakonfigurované tak, aby je odesílaly, a proč je výchozí šablona pro aplikace ASP.NET (Core) neodstraní ze souboru web.config?

Nemyslím si, že poskytování obrazového souboru, který může být o 44 % menší, je chyba. Za prvé, Sonar by to měl detekovat jako varování. Za druhé, proč System.Drawing.Bitmap kóduje obrázky do formátu PNG s touto strašlivou efektivitou?

Závěr

Sonar je ambiciózní projekt, který má podobný potenciál jako Lighthouse. Na straně objednávek se zdá, že Sonar je v rané fázi vývoje. Musí být prvním občanem v F12 Dev Tools, protože Google může prosadit svůj výklad standardů prostřednictvím Lighthouse v Chrome DevTools. Nakonec by měl být přijat týmem Bing, který má hluboké znalosti webu a může zlepšit kvalitu Sonaru tak, aby překonal Lighthouse.