<snip>
PG A RARE case, in the world of web applications??? Hardly!!!!!
PG 
PG I agree that in an optimal situation queries will not be based on
PG user input, but in the world of the web this is a pipe dream.  In
PG 99.99% of the cases there will be some dynamic element to a query. 
PG The only safeguard is to validate the hell out of the data.

> I don't know which web applications you develop, but the ones I have
> be developing the last 10 years all user interaction was done thrue
> forms where users where asked specific question, and the input to
> these specific questions where used as input in prepared statements.
> Eg. "select tuple1.table1, tuple1.table2, tuple3.table1 from table1,
> table2 where tuple1.table1 = tuple1.table2 and tuple1.table1=? and
> tuple3.table3>?" and so forth.      
> 
> In any case the users input where to be used in queries defined by
> the design of the application! 
> 
> I think you have misunderstod the concepts of making queries based on
> user input. It is not the users who should create the query, all to
> should do is provide the input to narrow down the queries.  
</snip>

I have not misunderstood the concepts of making queries based on user
input.

I think the issue here is we all need to clarify what we're referring to
as user input, because ultimately we are all saying the same thing.

1)  Hard coding a query into an application is good, if the situation
permits it;

2)  Letting a user select (or enter) a value(s) to be used in a query is
good, as long as you validate the hell out of said value(s);

3)  Letting a user arbitrarily enter unvalidated value(s) to be used in
a query is very very stupid and very very bad, and done far too often.

In a broader scope I would here consider to be user input ANY input
which is not hard coded into the application, and any input which is not
hard coded should be thoroughly examined before being used.

I've not misunderstood the concept, we're all saying the same thing,
just in different ways.

Cheers,
Pablo

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to