|
Тема
|
алтернатива на mysql_real_escape_string
|
|
Автор | almaak (Нерегистриран) |
Публикувано | 15.09.06 12:04 |
|
досега винаги, когато съм вкарвал нещо от форма в база данни съм ползвал, mysql_real_escape_string. само дето до сега не се бях замислял за проблемът с красотата на записаните неща доколкото знам mysql_real_escape_string слага пред всеки по-специален знак \. ако правилно съм схванал идеята, по този начин се предотвратява изпълнението на скриптове и други такива неща през формата. проблемът ми сега е, че когато записаното в базата данни се покаже в страницата, пред всяка кавичка има \, което изобщо не е красиво. да не говорим, че... всеки би могъл да се досети, какво съм използвал за ескйпване на стингове . та за туй въпросът ми е, има ли друга такава функция, която да е също толкова сигурна, но да не е толкова параноична .
всяка помощ ще е от полза.
| |
Тема
|
Re: алтернатива на mysql_real_escape_string
[re: almaak]
|
|
Автор |
Bълk (умора няма) |
Публикувано | 15.09.06 12:16 |
|
В отговор на:
проблемът ми сега е, че когато записаното в базата данни се покаже в страницата, пред всяка кавичка има \,
stripslashes
| |
Тема
|
Re: алтернатива на mysql_real_escape_string
[re: Bълk]
|
|
Автор | almaak (Нерегистриран) |
Публикувано | 15.09.06 12:53 |
|
много благодаря. само още един въпрос, ако не е твърде нахално. добре би било, преди stripslashes да ползвам strip_tags, нали?
| |
Тема
|
Re: алтернатива на mysql_real_escape_string
[re: almaak]
|
|
Автор |
Bълk (умора няма) |
Публикувано | 15.09.06 14:40 |
|
ми ... от в тагове си има неща които се ескейпват, трябва да махнеш ескейпване и след това ако имаш желание да махаш и самите тагове.
| |
Тема
|
Re: алтернатива на mysql_real_escape_string
[re: almaak]
|
|
Автор |
jmut (непознат) |
Публикувано | 28.09.06 10:11 |
|
mysql_real_escape_string е единственото правилно решение за да escapnesh правилно sql заявка преди да я пратиш към ДБ-то.
Другият начин е използването на prepared queries но затова ти трябва поне Mysql 4.1
Това че ти се получават допълнителни "\" означава че не си взел предвид magic_quotes.
Този код който ти давам се изплънява в началото на всеки скрипт за да си сигурен че всички променливи ти идват натурално :)) ...без ескейпване.
Общо взето това е и *единственото* място в което някога ще ти се налага да ползваш функцията stripslashes()
if (get_magic_quotes_gpc()) {
$in = array(&$_GET, &$_POST, &$_COOKIE);
while (list($k,$v) = each($in)) {
foreach ($v as $key => $val) {
if (!is_array($val)) {
$in[$k][$key] = stripslashes($val);
continue;
}
$in[] =& $in[$k][$key];
}
}
unset($in);
Колкото до addslashes() ще се радвам да чуя някаква смислена употреба...защото в настоящия момент на развитие на езика....тази функция е безмислена. Само не ми казвайте че се ползва за escaping на заявки към DB.
Успех
| |
Тема
|
Re: алтернатива на mysql_real_escape_string
[re: jmut]
|
|
Автор | чичo митko (Нерегистриран) |
Публикувано | 28.09.06 18:01 |
|
Колкото до addslashes() ще се радвам да чуя някаква смислена употреба...защото в настоящия момент на развитие на езика....тази функция е безмислена. Само не ми казвайте че се ползва за escaping на заявки към DB.
Защо да е безмислена - ами ако нямаш mysql extension към php-то ?
Функцията си е на мястото и има моменти, когато може да се ползва.
| |
Тема
|
Re: алтернатива на mysql_real_escape_string
[re: чичo митko]
|
|
Автор | jmut (Нерегистриран) |
Публикувано | 29.09.06 09:45 |
|
с какво ще пращаш заявки към базата данни ако нямаш mysql extension...
| |
Тема
|
Re: алтернатива на mysql_real_escape_string
[re: jmut]
|
|
Автор | чичo митko (Нерегистриран) |
Публикувано | 29.09.06 09:58 |
|
Защо базата трябва да е mysql ?
Защо да не ползвам PDO, ако е mysql ?
addslashes наистина има недостатъци в сравниени с mysql_real_escape_string и ако базата е mysql наистина е по-добре да се използва втората, но НЕ Е излишна в никакъв случай.
| |
Тема
|
Re: алтернатива на mysql_real_escape_string
[re: чичo митko]
|
|
Автор |
jmut (непознат) |
Публикувано | 29.09.06 16:18 |
|
Защото ако не е mysql ще ползваш prepared queries.... и аddslashes пак е безмислено.
Ако ползваш PDO пак ще ползваш prepared queries.
Така или иначе този "спор" няма да доведе до нищо. Лошо няма че съществува функцията. Просто не се употребява как трябва...и това исках да подчертая.
Толкоз от мен.
| |
|
|
|
|