Vlákno názorů k článku
phpMyAdmin VS Adminer

Adminer navíc detekuje verzi MySQL a odkazuje do dokumentace používané verze.

To phpMyAdmin dělá taky.

Ve výchozí konfiguraci nedovoluje phpMyAdmin zadat název serveru nebo se přihlásit pod uživatelem bez hesla.

Což je naprosto v pořádku, protože lidi kašlou na bezpečnost a opačný přístup vede ke spoustě volně dostupných rozhraní k MySQL. Dřív to v phpMyAdminu taky bylo naopak a dodnes jsou následky toho běžně vygooglovatelné.

Rámy a záložky

Přesně kvůli tomu je na každé stránce odkaz k otevření nového okna, které ho zduplikuje včetně rámů a stejně tak je možné ho uložit do záložek.

Možnosti rozšíření

Poměrně dost věcí je v phpMyAdminu také modulární a třeba přidat vlastní způsob autorizace je velmi jednoduché.

Adminer používá příkaz INSERT s klauzulí ON DUPLICATE KEY UPDATE, která jako jediná provede import správně.

To by mě zajímalo jak je definovaný „správný“ import :-).

Adminer si na druhou stranu dokáže z prvního řádku načíst seznam sloupců, které se pro zpracování souboru použijí.

Ve verzi 3.3 phpMyAdmin umí (kromě načtení seznamu sloupců) i automaticky vytvořit tabulku z CSV (nebo Excelu, ODS, XML a co já vím čeho ještě).

ALTER exportu, který slouží primárně k synchronizaci vývojového a produkčního serveru

Oproti tomu phpMyAdmin 3.3 má v sobě přímo synchronizaci serverů, kde je možné zobrazit rozdíly a zvolit co se má synchronizovat. Dále je možné logovat veškeré změny provedené v tabulce, tento log exportovat a použít ho na aktualizaci produkčního serveru.

ClickJacking

phpMyAdmin nedovolí běh ve frame, což je IMHO princip ClickJackingu, takže ochranu má.

Zamykání session

Bylo v phpMyAdminovi odstraněno asi před měsícem :-).

Prostě oba dva nástroje mají své výhody a podobné porovnání, jen vycházející lépe pro phpMyAdmina, bych taky zvládnul napsat ;-).

„Ve výchozí konfiguraci nedovoluje phpMyAdmin zadat název serveru nebo se přihlásit pod uživatelem bez hesla.“

„Což je naprosto v pořádku“

Tak s tím bych nesouhlasil. To je snad problém serveru a toho, kdo ten server instaloval a konfiguroval přístupy (pokud se tedy s nějakou konfigurací vůbec obtěžoval).
Není mi jasné, proč by klientská aplikace měla řešit blbé zabezpečení na straně serveru. To by taky mohla kontrolovat, aby se nemohl přihlásit uživatel s pitomým heslem jako „1234“ atd.

MySQL je ve výchozí konfiguraci přístupné jen z localhostu, takže to, že je přístupné bez hesla až tak nemusí vadit. Nicméně webová aplikace toto zpřístupní vzdáleně, což už je problém mnohem větší.

To samé platí s výběrem MySQL serveru – web server může běžet v DMZ nebo z něj může být jinak přístupný MySQL server, který z internetu dostupný není. Možností vybrat libovolný MySQL server pak otevíráme útočníkovi dveře, které by jinak byly zavřené.

A ano, lidi kašlou na nastavování, což není důvod, aby se výchozí konfigurace nesnažila aspoň o nějaké zabezpečení.

Díky Michale za přijetí pozvánky do této diskuse. Jsem rád, že se phpMyAdmin také vyvíjí a že připravovaná verze řeší i některé problémy popsané v článku.

Adminer i phpMyAdmin zobrazují prováděné SQL příkazy (ať už zadané ručně nebo provedené rozhraním). Adminer v těchto dotazech z klíčových slov dělá odkazy do dokumentace, u phpMyAdminu nic takového nepozoruji, ani jsem nenašel žádnou konfigurační direktivu, kterou by se to dalo zajistit.

Za chybu ohledně rámů a záložek v článku se omlouvám. Jak už jsem vysvětloval v této diskusi, postup běžného uživatele selhal.

Co se importu týče – pokud mám data, kterými chci aktualizovat tabulku (obvyklá situace), tak žádný ze způsobu phpMyAdminu neprojde. INSERT pouze vloží nová data a u starých skončí chybou. UPDATE naopak nevloží nová data. REPLACE nefunguje s cizími klíči (řádek nejdřív smaže a pak zase vloží), navíc může smazat víc řádků, než kolik jich vloží (pokud je v tabulce více unikátních klíčů).

phpMyAdmin má obranu proti ClickJackingu řešenou pomocí JavaScriptu, což se dá v IE triviálně obejít (atributem IFRAME SECURITY=„RES­TRICTED“ se v načteném dokumentu vypne JavaScript).

Odkazy na dokumentaci odpovídající verzi MySQL jsem měl na mysli obecně, takto v SQL příkazech se nezobrazují.

S tím importem asi záleží na tom, jak to obvykle člověk používá, já snad vždycky potřeboval INSERT IGNORE, takže tu „správnou“ věc jsem docílil i v phpMyAdminovi. Nicméně dává smysl tuto možnost přidat, tak to píšu do trackeru.

Ten IFRAME SECURITY=„RES­TRICTED“ by AFAIK měl být v MSIE 8 nějak vyřešený, pro starší se s tím bohužel nic dělat nedá.

SECURITY=„RES­TRICTED“ v IE8 nijak vyřešen není. IE8 zavedl hlavičku X-Frame-Options, kterou postupně převzaly i ostatní prohlížeče (Firefox zatím jen s extenzí Noscript) a která proti umístění stránky do rámu poskytuje systémovou ochranu nezávislou na JS. Adminer tuto hlavičku posílá.

Díky za nakopnutí, taky už jsem to mezitím našel a commitnul :-).

Nicméně to stejně neřeší ten samý problém s IE 7.