| Re: Form fields to database and back? [message #174555 is a reply to message #174538] |
Fri, 17 June 2011 20:03   |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
bobmct wrote:
> A typical field the user would enter would be like this:
>
> prd ="^ptmdtr-slb.bna.com^";
>
> I need to store it in the db field then be able to retrieve it and
> redisplay it exactly as entered.
>
> Currently I am using:
> $fld = htmlspecialchars_decode($fld);
> $fld = addslashes($fld);
>
> update table set field_name = '$fld'
This does not make sense. Either you are writing a CMS, then you should
store all markup verbatim (after removing potentially unwanted elements).
Or you are not, then you should not be receiving markup in the first place.
Unless you write for debugging, you could combine the calls:
$fld = addslashes(htmlspecialchars($fld));
But not even debugging merits two assignments here. (Note that this is just
an example. Do not use addslashes() here.)
If this is just a bad example, then consider this: You should avoid using
such PHP built-ins to escape parts of a database query. addslashes() is
inadequate() to the task. Use extension-provided functions, like
mysql_real_escape_string() or (better) prepared statements (as supported
e.g. by PDO, MySQLi, and sqlsrv, and implemented e.g. by Zend Framework).
> To retrieve and redisplay I use:
> $fld = $row['field_name'];
> $fld = htmlspecialchars($fld);
> $fld = stripslashes($fld);
I do not see why stripslashes() is needed (other than to compensate for the
pointless addslashes() before). htmlspecialchars() is only needed in the
output (so unless you are displaying a value twice, `echo' the return value
of htmlspecialchars() directly – unless your template engine/framework
already does that for you before, which it should be able to if it is any
good), and you should provide suitable additional parameters then (so that,
e.g., Unicode characters can be properly decoded and referred in the
markup).
Of course, you do not need or want to escape all dynamically generated
content, only where it matters (given a proper character encoding,
especially one that is the same in the database and the generated document,
and you making sure that no unwanted HTML is stored/retrieved in the first
place, there is no need to escape the generated content of elements.) Not
trying to escape things that do not need to be escaped can have positive
impact on the performance of a Web application (if you know the value is an
int – as made sure by a properly designed interface –, you don't have to
treat it like a string).
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]