Adminer 4.7.9
Školení, která pořádám 
O víkendu bylo hnusně, tak jsem se rozhodl projít backlog toho, co mi uživatelé Admineru zhruba za poslední rok napsali. Je těžké v tom oddělit zrno od plev, řada uživatelů klade úplně nesouvisející dotazy týkající se webového serveru, databáze, sítí, prostě čehokoliv. Popis chyby „udělal jsem XY a nefunguje to“ je celkem běžný. Pull-requesty kolikrát ani nepopíšou, jakou chybu se vlastně snaží opravit, velmi často jednu věc opraví, ale dvě další rozbijou. Uznávám, že upravovat kód Admineru je poměrně náročné proto, že funguje s různými databázovými systémy, s jejich různými verzemi a extenzemi, k tomu podporuje všechny verze PHP, kód není pořádně pokrytý testy (protože by byla šílenost je v takhle pestrém prostředí udržovat) a některé informace o kódu (které by mohly být v komentáři) jsou třeba jen v blame. Např. MS SQL nemám k dispozici a ani se mi v něm nechce Adminer testovat, tak jsem se rozhodl, že prostě přijmu všechny pull-requesty, které uživatelé pošlou. Ale ani to nevedlo ke kýženému stavu, protože pak chodí reporty chyb, že něco do určité verze Admineru fungovalo a pak přestalo. Pull request sice něco vyřešil pro některou verzi MS SQL, ale rozbil to v jiných. Bez holistického přístupu je to nekonečná práce.
I tak ale uživatelé nahlásili několik skutečných, reprodukovatelných a dobře popsaných chyb, za což jim děkuji. Přišlo i několik použitelných pull-requestů. Málokdy je přijmu bez jakýchkoliv úprav, ale drobné úpravy kódu, aby odpovídal stylu Admineru nebo pokryl nějakou dodatečnou funkčnost, mě tolik netrápí. Bezpečnostní experti odhalili i dvě bezpečnostní chyby, za které si sypu popel na hlavu a za jejichž zodpovědné nahlášení děkuji.
- V některých prohlížečích bylo možné dosáhnout self XSS – navštívení odkazu, kterým způsobím sám sobě XSS. Mně se chybu nepodařilo reprodukovat v Chrome ani ve Firefoxu, které před odesláním na server zakódují hodnoty URL parametrů, takže speciální znaky nutné pro útok se na stránce nezobrazí. Za určitých podmínek to ale asi možné bylo. (bug #775, rozbité od verze 4.7.0)
- V ovladačích pro Elasticsearch a ClickHouse se v případě HTTP kódu jiného než 200 zobrazila celá výsledná stránka jako chyba. Při použití redirectu (který vrací HTTP kód 3xx) se útočník mohl přesměrovat na webovou stránku na vnitřní síti, jejíž obsah se následně zobrazil. Osobně Adminer používám ve verzi jen pro MySQL, což tuto chybu potlačuje. Dále používám OTP, které tuto chybu útočníkovi také znepřístupní (obdobně se dá použít kontrola IP adresy).
- Při zadávání znaků pomocí IME se před dokončením zadávání znaku spustilo zvýrazňování syntaxe, což vstup prakticky znemožňovalo. (bug #747)
- V CSV exportu se nyní číselné řetězce uzavírají do uvozovek, pokud by jejich převod na číslo způsobil změnu v řetězci (např.
007). (bug #777) - V SQL příkazu se nově zvýrazňují odkazy. (PR #411)
- Adminer 4.7.3 přidal možnost odkazovat cizí klíče do jiných databází. Aktuální verze opravuje chybu, kde se pro odkaz na stejnojmennou tabulku v jiné databázi použily sloupce z odkazující tabulky. (bug #766)
- V předchozí verzi jsem kvůli PHP 8 narychlo vypnul všechna PHP varování. Nová verze je zase zapíná s potlačením těch, která Adminer nepotřebuje.
- V MySQL se před exportem nově vypne
sql_mode='ANSI_QUOTES', aby se dump dal následně importovat i tam, kde je tato volba vypnutá. (bug #749) - Adminer 4.7.8 vyřešil obejití kontroly připojení na privilegovaný port, bohužel to ale udělal nekompatibilně s PHP 8. (PR #409)
- MySQL ze záhadného důvodu v příkazu
SHOW FULL COLUMNSvrací výchozí hodnoty sloupců typu text v apostrofech (u ostatních sloupců bez apostrofů). Nový Adminer to bere v úvahu. (bug #779) - V PostgreSQL se nově exportují cizí klíče až po vytvoření tabulek. MySQL to odjakživa řeší vypnutím
foreign_key_checks, které v PostgreSQL není k dispozici. (PR #351) - V PostgreSQL se špatně zvýrazňovala syntaxe při použití dolaru. (bug #738)
- V PostgreSQL se zobrazovala definice pohledu daného jména z prvního schématu (a nikoliv toho aktuálního). (PR #392)
- PostgreSQL používá pro
bigint auto incrementpseudo-typbigserial. Tohle jsem rozbil ve verzi 3.0.0 před více než deseti lety a od té doby si toho nikdo nevšiml. (bug #765) Prosmallintse nově použijesmallserial. Bohužel se mi nepodařilo snadno vyřešit chybu, že zapnutí auto increment až ve změně tabulky nic neudělá. (bug #761) - PostgreSQL pro PDO nově podporuje PgBouncer za cenu odstranění podpory pro PostgreSQL < 9.1. (bug #771)
- PostgreSQL 10 nově podporuje
GENERATED ALWAYS BY IDENTITY. (PR #386) - PostgreSQL 10 nově podporuje rozdělené tabulky. (PR #396)
- Od PostgreSQL 11 se pro auto increment sloupce nově vytvoří primární klíč. Od této verze stačí příznak
PRIMARY KEYuvést u sloupce, ve starších verzích jen v definici tabulky. - Pokud do SQLite databáze nepřetržitě něco zapisovalo, tak byl Adminer prakticky nepoužitelný. Nová verze proto nastavuje
busy_timeoutna 500 ms, po které bude Adminer v případě zamčené tabulky čekat, než to vzdá. - V MS SQL se komentáře ořezávaly na 30 znaků, což je výchozí hodnota při přetypování na řetězec… (PR #376)
- Elasticsearch 6 kompletně mění práci s typy, Adminer na to reaguje. (PR #402)
- V MongoDB se konečně podařilo vyřešit problém, na který si stěžovala řada uživatelů – Adminer z bepečnostních důvodů blokuje připojení k databázi nechráněné heslem. Je to realizované tak, že se pokusí připojit bez hesla a pokud to projde, tak oznámí chybu. S původní extenzí to fungovalo, ale nová extenze chybu vrátí až po provedení prvního příkazu, takže samotné připojení bez hesla vždycky prošlo, což způsobilo chybu Admineru. (PR #405)
- V Adminer Editoru se při hledání ve všech tabulkách přetypují sloupce na řetězec. Adminer už to dělá dlouho. (bug #325)
- V Editoru byla v názvu exportovaného souboru na konci tečka.
Diskuse je zrušena z důvodu spamu.
© 2005-2024 