On July 13, 2009 09:48:54 am Haig Dedeyan wrote:
> On Monday 13 July 2009 14:31:09 tedd wrote:
> > At 3:53 PM -0400 7/12/09, Paul M Foster wrote:
> > >On Sun, Jul 12, 2009 at 09:07:45AM -0400, tedd wrote:
> > >
> > ><snip>
> > >
> > >> As for prepared statements, I'm no authority on them, but from what
> > >> I've read they are not going to be something I'll be practicing
> > >> anytime soon.
> > >
> > >Aside from Stuart's comments about slowness, what else have you read
> > >that makes you discount the use of prepared statements? The PDO class
> > >emphasizes that you're safe from SQL injection exploits, which seems a
> > >big plus.
> > >
> > >Paul
> > Paul:
> > As I said, I'm no authority. However as I have read, prepared
> > statements are for a limited set of instructions in MySQL. They can't
> > be used for everything. Why should I learn one way to do something
> > that isn't universal in the language?
> > Additionally, I think the way I sanitize data is sufficient AND I
> > understand it. *My* learning curve may introduce security problems
> > that I am not willing to risk, at this moment. As I said, I have more
> > than enough on my plate to digest -- including learning non-prepared
> > statements in MySQL.
> > Cheers,
> > tedd
> > --
> > -------
> > http://sperling.com http://ancientstones.com http://earthstones.com
> Generally speaking, what I have always done to avoid MySQL injection is to
> use mysql_real_escape_string() on all variables I'm chucking into the
> This won't avoid hacks that involve people trying to insert other types of
> code into your content, aka XSS, et al, though. What I do for cases like
> these is try to be as specific as possible when allowing users to enter
> data and try to sanitise it as much as possible.
> For example, a name field shouldn't contain anything other than letters, so
> you can write a regex for that. Phone number fields should only contain
> numbers, the odd + sign, and sometimes spaces and brackets if you're users
> are really fastidious with their input.
> Sometimes this isn't possible, as in the case of a lot of free-text entry
> boxes, so for those you should try and make some attempt to strip out tags
> or html encode the data prior to displaying it.
> Anyway, that's my take on it, and it seems to work for me, but I'm always
> welcome to know of other ways, as I'd prefer being told on the list than
> finding out the hard way! :p
for the phone #'s, I'm using int as the data type & storing each part of the
phone # in its own cell,
When it gets displayed, I add a dash in between each part of the phone #'s
(country code-area code-1st set of digits-last set of digits)