>> [To Jochem]
>> MS SQL Server is a pretty decent database product, and their profiler
>> shows exactly what was sent to the database, nothing more, nothing
less.
>
>And apparently you want to see more.
Yes, when I need too, I want to see the "real" sql query, not "exec sp_1
3", which is what a precompiled query looks like. Would "exec sp_1 3"
satisfy you? Since I can only see what is passed to the sql server then
I request that something better be passed to the sql server. The logic
of this argument is simple. (If the "real" sql could be passed in as a
comment in the same request then I would probably be just as happy.)
>> (Sort of like the way
>> assert() works in other languages.... when you debug you get one
>> thing, when to run you get another.)
>
>But leaving asserts on in production can hardly remain undetected since
they throw an exception.
It is like assert in that the source code doesn't have to be modified to
get different behavior. A quick change of the environment (compile w/ or
w/o debugging included) and the exact same source code gives you a
better debugging experience.
>> You two are really stuck on your positions and I'm only saying that
more
>> flexibility in the language would make more applications more secure
>
>I don't believe that. Security only works when it is enabled by
default.
>Security options that can be disabled will be disabled.
But security features that are not used do not increase security at all.
Better to disable them 1% of the time rather than avoid them 100% of the
time.
My central argument is that a security feature that some people (meaning
me) avoid because it has undesirable side effects that cannot be made to
go away when necessary without changing source code will not be used as
much as it should, so ultimately it is not actually providing as much
security it could be. Where possible, this situation should be
addressed. Since the cfqueryparam tag cannot be magically removed from
code when the situation comes up, it would be nice to have the server
treat it one way some times and another way at other times.
Ask yourself this: why does CF allow function argument type checking to
be disabled? Because there are times when you want it (developing) and
times when someone, somewhere might not. This feature (this option) was
implemented for a reason, and someone out there uses it. Granted, CF
probably only has this option because it makes things run faster, but
anyone who uses that option is implicitly giving up some safety. It is
each person's decision to disable it or not and CF gave them the option.
Sounds fair to me.
It seems to me that the only difference here is that SQL injection is so
scary that you can't imagine a situation where you would give it up, but
maybe, just maybe, a day will come when you really wish you could see
the real sql from the database server's point of view. On that day you
will be glad the *option* is available to you, or you will wish that
someone had thought to include it. Options is all I'm asking for. The
difficulty in implementing it (to try to squeeze as much safety out of a
non-bound mode) should not affect whether or not it is a good idea.
BTW, I have already submitted by wishlist request to macromedia and
unless our little discussion can have some bearing on that request I
will move along to other topics.
Thanks
Mark
-----Original Message-----
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 09, 2007 3:57 PM
To: CF-Talk
Subject: Re: cfquery: quotes vs queryparam
Gaulin, Mark wrote:
> Dave wrote:
>> But what exactly would this tag do, if not create a bound parameter?
> It sounds like what you really want is an off switch.
>
> Yes! I want an off switch so when debugging is more important than
> security, I can do that without changing any code!
And how long will it be before you switch it off in production so you
can see the values in the automatically generated emails your system
generates?
> (Sort of like the way
> assert() works in other languages.... when you debug you get one
> thing, when to run you get another.)
But leaving asserts on in production can hardly remain undetected since
they throw an exception.
> [To Jochem]
> MS SQL Server is a pretty decent database product, and their profiler
> shows exactly what was sent to the database, nothing more, nothing
less.
And apparently you want to see more.
> You two are really stuck on your positions and I'm only saying that
more
> flexibility in the language would make more applications more secure
I don't believe that. Security only works when it is enabled by default.
Security options that can be disabled will be disabled.
> Sounds like a win-win to me, but if
> defending the status-quo is all you want to do, then come and get me,
> because I kinda wish things would change.
I do not want to defend the status quo. In fact, I have several open
feature requests registered at Adobe in order to make cfqueryparam and
datasources in general safer. I just don't want to see any changes that
move in a direction that I feel is the wrong one.
Jochem
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
ColdFusion is delivering applications solutions at at top companies
around the world in government. Find out how and where now
http://www.adobe.com/cfusion/showcase/index.cfm?event=finder&productID=1522&loc=en_us
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:285897
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
