Page 1 of 2
Filtering/typecasting data: when to do this?
Posted: Thu Jan 06, 2011 4:05 am
by Technical
Filters can really slow down performance, so it's very important to know when use them.
Should I filter data that(excluding HTTP received of course, which I always filter):
1) Received from database
2) Passed as function arguments
3) Going to be saved into database
4) Received from objects
5) Going to be displayed to user
Re: Filtering/typecasting data: when to do this?
Posted: Thu Jan 06, 2011 5:16 am
by Jenk
3 and 5.
Re: Filtering/typecasting data: when to do this?
Posted: Thu Jan 06, 2011 5:23 am
by VladSun
I have a simple rule - every time data has to be put into a different "media" (e.g. DB, file, HTML display, XML display, etc.) (I call it "target context") an appropriate (best case - a tool provided by the "media" itself like *sql_real_escape, htmlentities, etc.) filtering/escaping/whatever-you-call-it should be done.
Re: Filtering/typecasting data: when to do this?
Posted: Thu Jan 06, 2011 6:32 am
by Technical
Thanks for the replies.
Should I typecast data received from database?
Re: Filtering/typecasting data: when to do this?
Posted: Thu Jan 06, 2011 11:22 am
by matthijs
The most important thing is that you understand why data needs to be filtered/escaped in each change of context. For example, if you have a user submitted string of text. That can contain quotes ( ' ) which can break (intentionally or not) the sql queries you run. So you escape them on putting them in the db.
Or a string of text, being retrieved from a db and shown in HTML. So the context becomes HTML, which means some things are/can be suddenly dangerous/unwanted. So you html escape or filter out unwanted HTML.
An important thing is to define correctly and make the distinction between filtering, validating and escaping. Those terms are often used wrongly or differently. In my definition, with filtering, you remove/change something. With escaping, you don't do that. You only make sure some data cannot cause problem when changing context (like when you use mysql_real_escape_string)
Re: Filtering/typecasting data: when to do this?
Posted: Thu Jan 06, 2011 11:50 am
by VladSun
Technical wrote:Should I typecast data received from database?
Well, even if DB "driver" supports PHP types, a "nullable" column value will break it.
Re: Filtering/typecasting data: when to do this?
Posted: Thu Jan 06, 2011 12:00 pm
by Technical
VladSun wrote:Technical wrote:Should I typecast data received from database?
Well, even if DB "driver" supports PHP types, a "nullable" column value will break it.
Sorry, my mistake.
I just found strange thing: SQLite allows you to store string in integer column if it's not a primary key. So than forced me to put intval() in my code to ensure I'll work with numeric value.
Re: Filtering/typecasting data: when to do this?
Posted: Tue Jan 11, 2011 9:05 pm
by josh
If a user input field should only contain numeric data, it should be filtered upon the form submission, and rejected if it doesn't validate (giving the user the opportunity to replace the value with a valid one)
Re: Filtering/typecasting data: when to do this?
Posted: Tue Jan 11, 2011 11:23 pm
by Technical
josh wrote:If a user input field should only contain numeric data, it should be filtered upon the form submission, and rejected if it doesn't validate (giving the user the opportunity to replace the value with a valid one)
Yes, as I've stated, I always filter HTTP-received data.
Re: Filtering/typecasting data: when to do this?
Posted: Wed Jan 12, 2011 1:36 am
by Christopher
I don't filter for any of your five points.
I think my rule is: filter data that comes from a external source (e.g. HTTP Request or data feed) and escape data that goes to an external source (e.g. database or HTTP Response).
Re: Filtering/typecasting data: when to do this?
Posted: Wed Jan 12, 2011 1:59 am
by josh
@Technical Filtering is the process of altering or changing data, for example escaping quotes. It is no substitute for validating your data!! (I even mixed up the two terms in my last post, just setting the record straight). You should always filter+validate your data.
Re: Filtering/typecasting data: when to do this?
Posted: Wed Jan 12, 2011 3:02 am
by Christopher
I didn't get into validation because it was not part of the topic -- it is also important. Both filtering and escaping are names for altering/changing data. But those words are used for different things and @technical nitpicking just muddies those useful meanings.
Re: Filtering/typecasting data: when to do this?
Posted: Wed Jan 12, 2011 3:12 am
by matthijs
My definitions of the three are
Code: Select all
// Filter something:
$x = 'abc123';
$y = filter($x);
$y is 'abc'; // the result is that unwanted stuff is filtered out
Code: Select all
// Validate something
$x = 'abc123';
$y = validate($x);
$y is bool true false; // the result is a yes/no answer to the question "Is this piece of data valid?
Code: Select all
// Escape something
$x = 'O'reilly';
$y = escape($x);
$db->insert($y);
$y is now inside the database as O'reilly, but the quote didn't cause any problems
Code: Select all
Or in case something is output as HTML
$x = 'some & thing';
$y = htmlentities($x);
echo $y; // outputs 'some & thing' in the source, but 'some & thing is displayed to the user
Re: Filtering/typecasting data: when to do this?
Posted: Wed Jan 12, 2011 6:15 am
by Technical
Okay, okay, seems that discussion went wrong way.
I'm not asking how to filter/validate, I'm asking what data should I filter/validate. Look at the first post, I wrote a list of options.
My second question was about forced typecasting. I meant, should I use intval(), floatval(), strval() on variables passed as function arguments, database received rows and etc.? Does it hurt performance much?
Re: Filtering/typecasting data: when to do this?
Posted: Wed Jan 12, 2011 6:47 am
by VladSun
Why would you need this? PHP is "typeless" language. Elaborate please
