On 5 Oct 2011, at 00:45, Tommy Pham wrote: > On Tue, Oct 4, 2011 at 4:11 PM, Stuart Dallas <stu...@3ft9.com> wrote: > On 5 Oct 2011, at 00:04, Mark Kelly wrote: > > > Hi. > > > > On Tuesday 04 Oct 2011 at 21:39 Stuart Dallas wrote: > > > >> http://stut.net/2011/09/15/mysql-real-escape-string-is-not-enough/ > > > > Thanks. I followed this link through and read the full message (having > > missed > > it the first time round), and while I find the idea of using base64 to > > sanitise text interesting I can also forsee a few difficulties: > > > > It would prevent anyone from accessing the database directly and getting > > meaningful results unless the en/decode is in triggers, or maybe stored > > procedures. No more one-off command-line queries. > > > > How would you search an encoded column for matching text? > > > > I'd be interested in any ideas folk have about these issues, or any others > > they can envisage with this proposal. > > Base64 encoding will work when the native base64 functions are available in > MySQL which will allow you to base64 encode the data into a statement like > INSERT INTO table SET field = FROM_BASE64("<?php echo base64_encode($data); > ?>") sorta thing. I'm still not a massive fan of that idea given that > prepared statements are an option, but it would work. > > -Stuart > > -- > Stuart Dallas > 3ft9 Ltd > http://3ft9.com/ > -- > > > Inserting and updating isn't the problem. I think Mark referring to is how > would that be implemented in this simple type of query: > > SELECT * FROM my_table WHERE col_name LIKE '%key word%'; > > If there's no viable mean to filter the data, that storage method/medium is > rather pointless, IMHO.
Go back and read what I wrote again. Base64 is only being used to transmit the data to MySQL - it's being stored in the database in its decoded form. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/
