On Mon, 2009-07-13 at 16:30 -0400, Bastien Koert wrote: > On Mon, Jul 13, 2009 at 4:18 PM, Haig Dedeyan<hdede...@videotron.ca> wrote: > > 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 > >> database. > >> > >> 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 > >> > >> -- > >> Thanks, > >> Ash > >> http://www.ashleysheridan.co.uk > > > > Hi Ashley, > > > > 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) > > > > Cheers > > > > Haig > > > > > > > > > > I too, store them as an int but then create a mask to show then user > the correct format based on country > > -- > > Bastien > > Cat, the other other white meat >
What about other data? Is what I'm doing already sufficient do you think? Thanks Ash www.ashleysheridan.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
