Abs,
On Thu, Sep 18, 2003 at 08:35:25AM +0100, Abs wrote:
> --- Daniel Kasak <[EMAIL PROTECTED]> wrote:
> > Abs wrote:
> >
> > >mysql and php question:
> > >the magic_quotes_gpc is set to 1. when i echo it to
> > >the browser, it shows the added slashes. i inserted
> > >these same values into a database. when i read the
> > >database values and printed them, i forgot to use
> > >stripslashes. but i was surprised to see that the
> > >slashes were already removed. now i know this
> > depends
> > >on magic_quotes_runtime, which i checked, was OFF,
> > so
> > >how did the slashes get removed without me
> > explicitly
> > >doing so?
> > >
> > >what's more interesting is that when i view the
> > data
> > >in the table using phpMyAdmin, the quote i put
> > wasn't
> > >escaped with a backslash. when i tried to do a
Correct, it isn't there, so you don't see it. See below where you repeat
your question.
> > >dump/export of the table, the output showed a
> > >backslash before the quote. so how come? the
Correct. If mysqldump didn't put it there, it wouldn't be a valid MySQL
query.
> > slashes
> > >should be showing when i say SELECT * FROM MYTABLE.
> > >
> > >abs
> > >
> > >
> >
> > I think this is why people recommend that you
> > *don't* use PHP's magic
> > quotes.
> > I hit this problem in a few areas and decided to
> > turn it off.
> >
> > Use PHP's functions:
> >
> > stripslashes() and
> > addslashes()
> >
> > You'll be sorry later if you don't, and continue
> > using magic quotes...
> >
>
<soapbox>
The recommended configuration of PHP has both magic_quotes_runtime and
magic_quotes_gpc off, which is a good thing IMHO. The whole magic quotes
is a hack anyway. Escaping (backslashing) is only needed when you put
the values in quoted strings, e.g. HTML parameters and MySQL queries.
The first case would need htmlspecialchars anyway, eliminating the need
for addslashes. The second case could have been solved more cleanly by
something like this:
mysql_query_params("UPDATE mytable SET mycolumn = ?", $gpcval);
This is how it's done in Perl DBI and some other database bindings and
stored procedures. This reads more cleanly anyway, especially if you
also need to manipulate $gpcvalue for this query. People would just need
to be taught to use this method. Maybe it's too late for that now.
By using magic quoting, users need to use stripslashes in places that
are unrelated to the code that needs slashes. People don't do that so you
see O\'Brien on their webpages. Or they do it too often, leading to
errors in subsequent MySQL queries. The distinction between sources of
strings (magic_quotes_gpc vs magic_quotes_runtime) doesn't help either.
Anyway, maybe the whole magic quotes thingy prevents some security
problems (XSS and SQL injections) in sloppy code.
</soapbox>
> that still doesn't answer the question though. if the
> variables already had the slashes in them because of
> magic_quotes_gpc, then shouldn't the table i inerted
> it into also have the slash in it?
Like someone else mentioned on the list a short while ago, the slashes
are only there in an attempt to make sure that queries are syntactically
correct, even when users don't think twice (or once).
Take this PHP statement:
mysql_query("UPDATE mytable SET mycolumn = '$gpcval');
Now suppose that someone inputs O'Brien with magic_quotes_gpc off. Then
$gpcvalue will just be O'Brien. The query will be:
mysql_query("UPDATE mytable SET mycolumn = 'O'Brien');
This is syntactically incorrect because the value is O and Brien' is
garbage that follows.
[
If $gpcvalue contained "'; DELETE from mytable" and your database
supports multiple queries (MySQL 5, 4.1?), you would just have lost all
data.
]
Now suppose that someone inputs O'Brien with magic_quotes_gpc on. Then
$gpcvalue will be O\'Brien. The query will be:
mysql_query("UPDATE mytable SET mycolumn = 'O\'Brien');
This is syntactically correct. The slash escapes the quote and MySQL
interprets the value as O'Brien, which is what you want. Having O\'Brien
in your database makes no sense.
You shouldn't use stripslashes on values you get from the database. That
is, unless your PHP configuration has magic_quotes_runtime set.
> magic_quotes_runtime ADDS slashes if it is ON, so it
> leaves the data untouched if it's OFF (if this is
> incorrect, the documentation needs to be updated).
>
> hence, when i retrieved the data from the db, the
> quotes should have still been there. and the o/p to
> browser, phpMyadmin (and macromedia dreamweaver's
> "test" window) all don't show any slashes in the data,
> but 'export' in phpMyadmin adds slashes to the text it
> outputs.
> magic_quotes_gpc is On
> magic_quotes_runtime is Off
> magic_quotes_sybase is Off (to be sure)
>
> another thing that comes to mind is...
> does mysql store the data in the .tbl/.frm files in
> their text form? or is the slash we add there "just"
> to tell mysql to disregard the significance of the
Correct, it is just there to escape the next character.
> next character? the 2nd one seems logical considering
> that mysql would read data per column in the specific
> size it's supposed to be (and not pay attention to the
> mean of what it's reading). so if a varchar(50) column
> has the data: `qwer'y\19o` then it knows that it
> should read and return 10 chars/bytes.
>
Regards,
Fred.
--
Fred van Engen XB Networks B.V.
email: [EMAIL PROTECTED] Televisieweg 2
tel: +31 36 5462400 1322 AC Almere
fax: +31 36 5462424 The Netherlands
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
