PHP and MySql

[gzerphey]

Thank you in advance for helping.

I have a bit of a problem with MySQL and PHP working together. More
specifically when i use htmlspecialchars() to encode my text then load
it into the database, it is interpreting the special characters and
decoding them.

Is there any way that I can perserve this coding and make sure it says
in my database?

Example:

Here is what is entered -- t%20t
Here is what is showing in the database now -- t t
here is what I would like to see -- t%20t

Thank you again,

[Jerry Stuckle]

gzerphey wrote:

Thank you in advance for helping.

I have a bit of a problem with MySQL and PHP working together. More
specifically when i use htmlspecialchars() to encode my text then load
it into the database, it is interpreting the special characters and
decoding them.

Is there any way that I can perserve this coding and make sure it says
in my database?

Example:

Here is what is entered -- t%20t
Here is what is showing in the database now -- t t
here is what I would like to see -- t%20t

Thank you again,

htmlspecialchars() is for displaying special characters, not storing
them in the database. You should be using it to display the data, not
place it in the database.

What you should do is store the data as is entered (use
mysql_real_escape_string() to handle any database-specific special
characters).

Then when you pull it out of the database, you can use
htmlspecialchars() before displaying the data.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[BKDotCom]

and why are you storing a url-encoded string?

[Pedro Graca]

gzerphey wrote:

I have a bit of a problem with MySQL and PHP working together. More
specifically when i use htmlspecialchars() to encode my text then load
it into the database, it is interpreting the special characters and
decoding them.

Is there any way that I can perserve this coding and make sure it says
in my database?

Example:

Here is what is entered -- t%20t
Here is what is showing in the database now -- t t
here is what I would like to see -- t%20t

What happens when you add this line right at the top of your script,
at line 1?
<?php header('Content-Type: text/plain'); ?>

--
I (almost) never check the dodgeit address.
If you *really* need to mail me, use the address in the Reply-To
header with a message in *plain* *text* *without* *attachments*.

[Andrew C]

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:GJ******************************@comcast.com. ..

gzerphey wrote:

>Thank you in advance for helping.

I have a bit of a problem with MySQL and PHP working together. More
specifically when i use htmlspecialchars() to encode my text then load
it into the database, it is interpreting the special characters and
decoding them.

Is there any way that I can perserve this coding and make sure it says
in my database?

Example:

Here is what is entered -- t%20t
Here is what is showing in the database now -- t t
here is what I would like to see -- t%20t

Thank you again,

htmlspecialchars() is for displaying special characters, not storing them
in the database. You should be using it to display the data, not place it
in the database.

What you should do is store the data as is entered (use
mysql_real_escape_string() to handle any database-specific special
characters).

(Apologies for thread hijacking...)

I took a look at the PHP documentation for mysql_real_escape_string()
(http://uk.php.net/manual/en/function...ape-string.php) and saw
an example of an 'SQL Injection Attack' (Example 2 on that page) along with
their solution (Example 3).

In their example, wouldn't magic quotes be sufficient to thwart the attack?

In their example, someone supplies $_POST['password'] of "' OR ''='". With
magic quotes on, this would become "\' OR \'\'=\'", correct? When used in
their example query, this would be:

SELECT * FROM users WHERE user='username' AND password='\' OR \'\'=\''

Wouldn't that be okay?

I would be grateful if someone could point out any misunderstandings I have.

Thanks.

A.

[Jerry Stuckle]

Andrew C wrote:

"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:GJ******************************@comcast.com. ..

>>gzerphey wrote:

>>>Thank you in advance for helping.

I have a bit of a problem with MySQL and PHP working together. More
specifically when i use htmlspecialchars() to encode my text then load
it into the database, it is interpreting the special characters and
decoding them.

Is there any way that I can perserve this coding and make sure it says
in my database?

Example:

Here is what is entered -- t%20t
Here is what is showing in the database now -- t t
here is what I would like to see -- t%20t

Thank you again,

htmlspecialchars() is for displaying special characters, not storing them
in the database. You should be using it to display the data, not place it
in the database.

What you should do is store the data as is entered (use
mysql_real_escape_string() to handle any database-specific special
characters).

(Apologies for thread hijacking...)

I took a look at the PHP documentation for mysql_real_escape_string()
(http://uk.php.net/manual/en/function...ape-string.php) and saw
an example of an 'SQL Injection Attack' (Example 2 on that page) along with
their solution (Example 3).

In their example, wouldn't magic quotes be sufficient to thwart the attack?

First of all, magic_quotes is bad. It changes the data without the
user's knowledge. Even worse, it can be turned on or off - either
breaking scripts or requiring extra gyrations to handle either on or off.

Second, mysql_real_escape_string() is a mysql function sensitive to the
charset in use in the table. It is also designed specifically for
inserting into/updating a MySQL database. magic_quotes is a generic
function, not sensitive to character sets.

In their example, someone supplies $_POST['password'] of "' OR ''='". With
magic quotes on, this would become "\' OR \'\'=\'", correct? When used in
their example query, this would be:

SELECT * FROM users WHERE user='username' AND password='\' OR \'\'=\''

Wouldn't that be okay?

I would be grateful if someone could point out any misunderstandings I have.

Thanks.

A.

While magic_quotes *could* be sufficient, it's much better to use the
function designed for the job.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Pedro Graca]

Jerry Stuckle wrote:

Andrew C wrote:

>>
In their example, wouldn't magic quotes be sufficient to thwart the attack?

First of all, magic_quotes is bad. It changes the data without the
user's knowledge. Even worse, it can be turned on or off - either
breaking scripts or requiring extra gyrations to handle either on or off.

Second, mysql_real_escape_string() is a mysql function sensitive to the
charset in use in the table. It is also designed specifically for
inserting into/updating a MySQL database. magic_quotes is a generic
function, not sensitive to character sets.

Third, magic_quotes will be taken away from PHP6.
http://www.corephp.co.uk/archives/19...for-PHP-6.html

--
I (almost) never check the dodgeit address.
If you *really* need to mail me, use the address in the Reply-To
header with a message in *plain* *text* *without* *attachments*.

[Andrew C]

"Pedro Graca" <he****@dodgeit.comwrote in message
news:sl*******************@ID-203069.user.individual.net...

Jerry Stuckle wrote:

>Andrew C wrote:

>>>
In their example, wouldn't magic quotes be sufficient to thwart the
attack?

First of all, magic_quotes is bad. It changes the data without the
user's knowledge. Even worse, it can be turned on or off - either
breaking scripts or requiring extra gyrations to handle either on or off.

Second, mysql_real_escape_string() is a mysql function sensitive to the
charset in use in the table. It is also designed specifically for
inserting into/updating a MySQL database. magic_quotes is a generic
function, not sensitive to character sets.

Third, magic_quotes will be taken away from PHP6.
http://www.corephp.co.uk/archives/19...for-PHP-6.html

Thanks to you both for the points of view and the link.

A.