Witam
Nie rozumiem przynajmniej jednej rzeczy, pracuję na PHP5. Magic Quotes jest włączony i dziwię się...

Napisałem dla testów taki mały programik, proszę zobaczyć niżej. I nie rozumiem dlaczego jesli wpisauję w formularzu np: "O'Connor" to wszystko działa bez zarzutu, w bazie danych jest to co wpisałem, czyli "O'Connor". Dlaczego nie pojawiają sie błędy, przecież użyłem znaku: '.
Nie zastosowałem nigdzie funkcji mysqli_real_escape_string, a wszystko działa. A jeśli wszystko działa, to po co używać funkcji mysqli_real_escape_string... ? Za uwagę dziękuję.

[PHP] pobierz, plaintext 
<?php
$t = ($_POST['tekst']);
 
 
$con = mysqli_connect(localhost, Jach, Pass, history);
$q = "update wars set event='$t' where id=1";
$r = mysqli_query($con, $q);
 
if ($r)
echo "Wykonano zapytanie";
?>
 
<form action="us.php" method="POST">
Wpisz <input type="text" name="tekst"></input>
<input type="submit"></input>
</form>
</body>
</html>
[PHP] pobierz, plaintext 

Nie jestem też pewny różnicy między 'magic quotes' a 'mysqli_real_escape_string' jedno i drugie wstawia backslashe przez problematyczne znaki. Wg. mnie różnica jest taka, że funkcja mysqli_real_escape_string robi to w momencie gdy dane wpisywane są do bazy danych, a magic quotes zawsze w formularzach...



PS
To forum jest bardzo zatłoczone, piszę rzadko

Nie wiem czy dobrze rozumiem... najpierw pytasz nas dlaczego twój skrypt działa chociaż wiesz, że to przez magic_quotes? Mysql_real_escape_string możemy na przykład użyć gdy mq są wyłączone, logiczne prawda?



No tak, strasznie trudno dopchać się do tego okienka, gdzie się składa posty, wiem coś o tym

No dobrze... MQ są włączone, ale w takim razie w bazie danych powinno być "O\'Connor" a tymczasem jest "O'Connor" A ja nigdzie nie używam stripslashes().

magic_quotes w niektórych szczęśliwych warunkach można ominąć ;> Rzuć okiem na tego linka:
http://shiflett.org/blog/2006/jan/addslash...l-escape-string

Niezupełnie, choć może to zależeć od konfiguracji serwera, ale przy domyślnych ustawieniach poniższe zapytania są równoważne i działają tak samo.

[SQL] pobierz, plaintext 
INSERT INTO logs (name) VALUES ("O'Connor");
INSERT INTO logs (name) VALUES ("O\'Connor");
[SQL] pobierz, plaintext 

Czyli dodają do pola name tabeli event wartość O'Connor.
Magic quotes są niepraktyczne i zostaną usunięte w PHP 6.0.

Magic quotes to zło. Sam ostatnio sie na nie wkurzałem. Dlaczego? Bo domyślnie moje zapytania ujmują wartości pól do bazy w pojedyncze apostrofy. Używalem więc mysql_real_escape_string i nie wiedziałem, że jakiś baran na hostingu włączył MQ. Pół dnia debugowałem własne skrypty, dodawalem stripslashes, htmlentities_decode i inne cuda by zrozumieć czemu do bazy idzie prawidłowo, a formularz mi mnoży znaki ucieczki, albo do bazy szlo źle, ale formularz pokazywał dobrze. Zwłaszcza, że całość to byla niezla kombinacja POST i 2 wywołań AJAXowych w jednym formie. Głupiałem szczególnie przy var_dumpie zapytania i wartości pól formularza, bo każde pokazywało co innego Dopiero gdy użyłem phpinfo i zauważyłem tam magic quotes -> ON to mało nie kopnąłem stacji roboczej i rwałem niemalże włosy z głowy. O ile więc przykład mortus ostatni jest poprawny to moje zwyczajowe pisanie zapytań:

[SQL] pobierz, plaintext 
INSERT INTO logs (name) VALUES ('O'Connor');
INSERT INTO logs (name) VALUES ('O\'Connor');
[SQL] pobierz, plaintext 

tutaj przez magików się wywalało. Za to jego zrobiłoby burdel w pierwszym przypadku dla tych dwóch i tylko drugi jest poprawny.

[SQL] pobierz, plaintext 
INSERT INTO logs (name) VALUES ("Jakiś "tytuł" książki");
INSERT INTO logs (name) VALUES ("Jakiś \"tytuł\" książki");
[SQL] pobierz, plaintext 

Jeszcze weselej jest w przypadku htmlspecialchars i innych funkcji, ponieważ domyślnie mają one ustawione ENT_COMPAT, czyli dodają znak ucieczki TYLKO dla podwójnego apostrofu i nie dodają go przed pojedynczym. To myli bardzo wiele osob. Ogólnie jest wielki problem przez to dla początkujących z dobrym i poprawnym stosowaniem ucieczki w zapytaniach do bazy. Jeśli do tego dorzucimy jeszcze fakt, że w polach input dla atrybutu value objętego w podwojny apostrof nie może się pojawić podwójny apostrof, nawet poprzedzony znakiem ucieczki (!) bo inaczej przeglądarka nie wie jak to zinterpretować i zwyczajnie uznaje to za błąd, to mamy jeszcze większy burdel (tutaj musimy się posłużyć htmlentities przy wpisywaniu danych z bazy a przed zapisem użyć html_entities_decode + strip_tags z "whitelistą") i kod dziurawy jak ser szwajcarski pod kątem bezpieczeństwa u słabo znających niuanse zabezpieczeń.