[DB-SIG] In praise of pyformat

Art Protin aprotin at research.att.com
Wed Aug 15 15:44:56 CEST 2007


Dear folks,
    Carsten Haese wrote:

>On Tue, 2007-08-14 at 10:18 -0400, Mike Meyer wrote:
>  
>
>>>How often does an identifier come from an untrusted source?
>>>      
>>>
>>Um, how about in every web-based app that has a real search facility?
>>One that lets the user specify which column(s) they want to check, or
>>that can search multiple tables?
>>    
>>
>
>Even if you take an identifier directly from an untrusted source, nobody
>is forcing you to stick it into a query unchecked.
>  
>
The better question is why is anybody letting him.

It is the worst form of programming to use unchecked data.

It is garbage like that that make so many systems insecure and the Net into
a mass of botnets.

So is he arguing that he needs tools to check & validate the values before
using them as table or column names?

>Anyway, I don't doubt that you often need to put unchecked identifiers
>from an untrusted source into queries, but I think you're in a very
>small minority compared to the general population of database
>application developers. I don't think that the DB-API spec should be
>weighed down by requiring a feature of such little general use, but
>you're welcome to write a reusable toolkit module that lives outside of
>and on top of DB-API. Of course you'll need to code some per-database
>logic that defines whether the database accepts delimited identifiers
>and what the delimiter is, but you only need to do this once for every
>database you plan on supporting.
>
>Keep in mind that this is just my opinion, and I don't speak for the
>entire DB-SIG community. It's your right to post a proposal and ask for
>a vote.
>
>  
>
Sorry, if I seem a little harsh, but this is apparently yet another of 
my hot buttons.


    Thank you all,
    Art Protin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070815/ff6fcc50/attachment.html 


More information about the DB-SIG mailing list