2009/10/16 Adam Pigg <[email protected]>: > On Thursday 15 October 2009 20:22:15 Jaroslaw S wrote: >> 2009/10/15 Adam Pigg <[email protected]>: >> >> This move was made necessary by a security fix in libpq itself. As it >> >> turned out, its escaping function needs to know the encoding the string >> >> is in, because some multibyte encodings have characters that contain the >> >> byte that in ASCII or UTF-8 would have been e.g. a single quote. >> >> >> >> So for example you might have a two-byte character consisting of some >> >> byte X and one that matches the ASCII character "'": X' >> >> >> >> In that case, the naïve previous escaping function would just double >> >> that byte to "escape" it, producing X'' and voilà: a closing quote has >> >> been injected into a string--by the exact function that's supposed to >> >> prevent it. >> >> >> >> I think your options are: >> >> >> >> a) Write your own escaping function based on your own knowledge of the >> >> encoding that the code is going to run in. I suppose Qt has some >> >> facility for breaking a string in the current locale's encoding down >> >> into unicode characters. >> > >> > Jeroen, >> > >> > Thanks for getting back, is it just the ' character which needs escaped >> > by doubling it? >> > >> > In which case, a QString::replace() could suffice, Jaroslaw, the main >> > kexi dev can advise on that. >> >> Guys, >> Thanks for continuing the discussion here. >> QString::replace() works in test cases but in pessimistic case it's O(n^2). >> I do recommend using const QChar * QString::constData () const- >> iterating over the \0-terminated list. >> >> If we implement our escaping (doesn't libpq itself have it if not >> libpqxx?), it's good idea to implement at least >> KexiDB::Driver::valueToSQL(), escapeString(), and check if >> escapeBLOB() is OK. > > I think in this case libpq wouldnt help because it is libpq's requirement to > have a connection to be able to escape properly based on the encoding of the > database. (?) > > Does mysql/other db's we support not have the same issue? Could the proper > solution not be to move Driver::escape* to Connection::escape*, that way > strings could be escaped based on the encoding of the connection in use.
I have nothing against it so far. The only thing is that we may need to keep the Driver::escape* functions (maybe with extra "encoding" parameter) too, for cases when we want to encode strings before we have working connection. That's assuming there's such a case in the wild. -- regards / pozdrawiam, Jaroslaw Staniek Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org) KDE Libraries for MS Windows (http://windows.kde.org) http://www.linkedin.com/in/jstaniek _______________________________________________ Kexi mailing list [email protected] https://mail.kde.org/mailman/listinfo/kexi
