Тук не съм съгласен с Бил и мисленето на Atomix е по-подходящо. Освен ако не може да се докаже друго, отговорът на Бил значително увеличава риска базата данни да бъде компрометирана.
Може би за много опитни разработчици има друга защита, но за други разработчици предоставянето на пълен, неограничен достъп на скрипт да прави ~всичко~ към база данни изисква проблеми, когато няма нужда.
Тук трябва да се използва принципът на най-малките привилегии. За MySQL имайте супер потребител с всички привилегии, който се използва за създаване на таблици, премахване на база данни и т.н. В идеалния случай това потребителско име и парола никога не се виждат в PHP файл или файл на уеб сървъра. (Използвам PHP като пример, но той се отнася и за други уеб приложения). Бихте използвали това потребителско име и парола само с нещо като PHPMyAdmin или MySQL Workbench.
След това, за PHP скриптове, имайте един с необходимия минимум, като просто INSERT, SELECT, UPDATE, може дори да не ИЗТРИЕТЕ, в зависимост от вашия PHP скрипт. Това ще бъде в PHP файловете, тоест всъщност само ЕДИН файл ИЗВЪН корена на документа, както се препоръчва от повечето.
Причината е следната:да, не се нуждаете от MySQL потребител за всеки потребител на уеб приложение. Но принципът на най-малката привилегия ( http://en.wikipedia.org/wiki/Principle_of_least_privilege ) трябва да се прилагат. Ако по някакъв начин вашият MySQL супер потребител е компрометиран, защото случайно сте кръстили вашия MySQL скрипт за свързване като .txt вместо .php, или някой е получил достъп до файловете на уеб сървъра, най-малкото „най-лошото“, което може да направи, е ИЗБЕРЕТЕ, АКТУАЛИЗИРАЙТЕ и ВМЪКНЕТЕ. .. Което, въпреки че може да причини големи проблеми така или иначе, не е толкова лошо, колкото да им дадете DROP DATABASE, DROP TABLES и много по-лоши неща.
Освен това, в настоящия ми проект поради гъвкави практики за разработка (не работя за, но препоръчвам http://www.agilealliance .org/ ), един или двама „нетехнологични“ членове на екипа директно използват PHPMyAdmin, за да правят директни промени в базата данни MySQL. Това е така, защото не се изисква създаване на CMS за просто директно въвеждане на данни. В този случай за него е подходящ трети потребител на MySQL с разумни, но отново „достатъчни“ привилегии. Не искаме да осакатим члена на екипа с твърде малко привилегии, но разбира се, той не трябва да може случайно да изтрива или променя неща.
Тъй като MySQL няма РОЛИ (от момента, в който е зададен първоначалният въпрос и според Бил), разрешаването на който и да е уеб скрипт да осъществява достъп до MySQL само с един супер потребител е много рисковано.
