y are procedures better? (was: RE: Securing CF Apps.)
> Yes, we are having a generic technical debate, and what I am saying is
> that
> when the team setup or hierarchical setup is not ideal, separating
> work out
> makes the project move along faster. Stored procs come into play here
o: CF-Talk
Subject: RE: why are procedures better? (was: RE: Securing CF Apps.)
> I certainly understand your position. But what does that have
> to do with comparing stored procedures to queries? It may
> matter in your particular situation, but we are supposed to
> be having a generic
t; Steve
>-Original Message-
>From: Matt Liotta [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, March 24, 2004 10:26 AM
>To: CF-Talk
> Subject: Re: why are procedures better? (was: RE: Securing CF Apps.)
>
>Maybe I don't understand your set
So are you advocating cfincludes with queries instead of stored procs?
Steve
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 10:26 AM
To: CF-Talk
Subject: Re: why are procedures better? (was: RE: Securing CF Apps.)
Maybe I don&#
>
> psycho nazi dba's need to first get over themselves...
>
> a view to the tables can obscure enough if that's the reason...
>
Now Tony, I think thats a bit strong! Some companies employ people to know
exactly whats going on with the DB. More a reflection of the value of
information and the c
- Original Message -
From: "Steve Nelson"
Do
> you have a development Oracle server you could try this on? I'm very
curious
> if there is a difference.
I haven't tested since we switched to CFMX, but on CF 5.0 with Oracle 8.17,
the "injected" sql would fail as invalid when it hit the dr
- Original Message -
From: "Greg Luce"
> Have you used ER Studio?
Nope, I use SQL Navigator & SQL Plus, Oracle behind those. Don't think
there's any auto-generating of stored procs in it. Don't think my boss would
think it worthwhile to plop down more money just for that, either.
[Todays
Maybe I don't understand your setup. In some CFM, you have to either
call cfquery or cfstoredproc. If you need to change either the query or
the stored procedure, you will need to edit this file. Now in either
case, you could simply use a cfinclude to separate out either into a
separate file th
>
> > The problem I always have with this example, despite the fact that 9/10
> > the example itself doesn't work, is that it takes 2 minutes to set up
> > appropriate users for databases with appropriate grant levels and you
> > can even set the statements that can be executed in the DNS sett
> I'm not quite clear on this. Of course SP's aren't the only way of
> separating business logic from presentation but aren't they one
> possible
> means of doing so? SP's allow developers to abstract or separate
> server-side
> functions from the client-side GUI. Multiple statements and
> c
> Maybe I wasn't clear in my reply to that statement. There is
> nothing inherent about stored procedures which makes them
> better for separating out work. It is in fact the same amount
> of work to separate queries as it is stored procedures.
Well... As I already pointed out:
Developer1 - Us
Stephen Moretti wrote:
>>Stephen Moretti wrote:
>>> You are quite correct.
>>>
>>> Jochem's example will wind up with all the DROP TABLE junk in the text
>>> field.
>>
>> Read again what I wrote about C-style escaping. Or just test it.
>
> Blows up on mySQL, but I see your point for less secure d
Message-
> From: Matt Liotta [mailto:[EMAIL PROTECTED]
> Sent: 24 March 2004 13:10
> To: CF-Talk
> Subject: Re: why are procedures better? (was: RE: Securing CF Apps.)
>
>
> The use of cfquery vs cfstoredproc has nothing to do with
> separation of
> presentation f
> Stephen Moretti wrote:
> > You are quite correct.
> >
> > Jochem's example will wind up with all the DROP TABLE junk in the text
> > field.
>
> Read again what I wrote about C-style escaping. Or just test it.
>
Blows up on mySQL, but I see your point for less secure databases like
Oracle..
> > That is a myth. Stored procedures are only faster than
> > dynamic queries; not prepared statements. In fact, in some
> > cases it is possible for a stored procedure to actually be
> > slower than a dynamic query.
>
> This is simply your opinion which differs greatly from the DBAs
> I've be
> Yes, we are having a generic technical debate, and what I am saying is
> that
> when the team setup or hierarchical setup is not ideal, separating
> work out
> makes the project move along faster. Stored procs come into play here
> in
> that someone can tackle this aspect while other things
> This is simply your opinion which differs greatly from the DBAs I've
> been involved with.
>
It isn't my opinion; it is an easily provable fact. Go ask your DBAs
what the difference in execution between a prepared statement and a
stored procedure is. The answer is nothing. But, don't take my w
> I certainly understand your position. But what does that have
> to do with comparing stored procedures to queries? It may
> matter in your particular situation, but we are supposed to
> be having a generic technical debate.
Yes, we are having a generic technical debate, and what I am saying i
> Well not all of us are in positions to control every aspect of a
> project..
> Nor are the people that are in charge always in line proper ways of
> doing
> things. I'm just another person on the lower end of the totem pole. If
> everything ran as it should we wouldn't be having this conver
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 9:13 AM
To: CF-Talk
Subject: Re: why are procedures better? (was: RE: Securing CF Apps.)
> I don't think there have been convincing arguments that SPs help from
> a security stan
> From: Jochem van Dieten
>
> This type of coding can be insecure. Just imagine what would
> happen in Oracle, MySQL or any other database that use
> C-style escaping when combined with:
> "h4ck3r\'; DROP TABLE users; COMMIT; --">
But if you're using CFQUERYPARAM, then that wouldn't effect any
ination of several items. The
only way I've done that is with a dynamically built query within a stored
proc and from what I gather, you lose all speed benefits with that design.
--
marlon
> Subject: Re: why are procedures better? (was: RE: Securing CF Apps.)
>
> > I don't
Stephen Moretti wrote:
> You are quite correct.
>
> Jochem's example will wind up with all the DROP TABLE junk in the text
> field.
Read again what I wrote about C-style escaping. Or just test it.
> If you try that against a numeric field, then you wind up with invalid
> SQL which will throw a
the quotes, not the database. Do
you have a development Oracle server you could try this on? I'm very curious
if there is a difference.
Steve Nelson
-Original Message-----
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 3:34 AM
To: CF-Talk
Subject: RE: w
etter handle on the data make someone a better
coder since the get the whole picture???
-Original Message-
From: Stephen Moretti [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 9:09 AM
To: CF-Talk
Subject: Re: why are procedures better? (was: RE: Securing CF Apps.)
You are
> If your application is properly modularized there shouldn't
> be all those different things in the same file anyway.
Well not all of us are in positions to control every aspect of a project..
Nor are the people that are in charge always in line proper ways of doing
things. I'm just another pers
, March 24, 2004 3:34 AM
> To: CF-Talk
> Subject: RE: why are procedures better? (was: RE: Securing CF Apps.)
>
> This type of coding can be insecure. Just imagine what would happen in
> Oracle, MySQL or any other database that use C-style escaping when
> comb
> I don't think there have been convincing arguments that SPs help from a
> security standpoint, but from a performance standpoint I don't think
> it's debatable.
>
That is a myth. Stored procedures are only faster than dynamic queries;
not prepared statements. In fact, in some cases it is possi
Yeah, but CF will double up those quotes automatically. At least I thought
it did.
Steve
-Original Message-
From: Jochem van Dieten [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 3:34 AM
To: CF-Talk
Subject: RE: why are procedures better? (was: RE: Securing CF Apps
t: Wednesday, March 24, 2004 8:37 AM
To: CF-Talk
Subject: RE: why are procedures better? (was: RE: Securing CF Apps.)
I cant see the correlation either...
psycho nazi dba's need to first get over themselves...
a view to the tables can obscure enough if that's the reason...
and Im not sur
> Finally, I work in small teams quite often where we all need to make
> bets
> use of our time, so sometimes if we are pressed for time, one person
> will
> write the stored procs, while another works on the pages and another
> the
> layout and UI. Imagine the hassle of trying to work on the
ast time I bought ER Studio it was around $800, I'm sure it's
more now but it's one of my favorite tools.
Greg
-Original Message-
From: Deanna Schneider [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 8:39 AM
To: CF-Talk
Subject: Re: why are procedures better? (
> I find that the most valid reason for using stored procedures
> is for transaction processing. If I need to tie several
> pieces of functionality together in one database hit, then
> I'll put it in a stored proc. For example, I'm working on a
> nested set procedure right now, where I need to
> I find that the most valid reason for using stored procedures is for
> transaction processing. If I need to tie several pieces of
> functionality
> together in one database hit, then I'll put it in a stored proc. For
> example, I'm working on a nested set procedure right now, where I
> need
there ya go...
a valid reason...however it has no bearing on security, more on
functionality...
good stuff
-Original Message-
From: Deanna Schneider [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 8:39 AM
To: CF-Talk
Subject: Re: why are procedures better? (was: RE
Original Message-
From: Stephen Barry [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 24, 2004 5:23 AM
To: CF-Talk
Subject: RE: why are procedures better? (was: RE: Securing CF Apps.)
While not wanting to get into the whole Stored Procedures V
argument, I have to say there are times wh
-Original Message-
From: Matt Liotta
If that's all, I guess I'll continue to use cfquery.
I find that the most valid reason for using stored procedures is for
transaction processing. If I need to tie several pieces of functionality
together in one database hit, then I'll put it in a stored
them - while I'm a big fan of separating business logic from
> presentation,
> for pure development speed you can't beat .
>
> - Steve Barry
>
> > -Original Message-----
> > From: Matt Liotta [mailto:[EMAIL PROTECTED]
> > Sent: 24 March 2004 01:48
&
ion,
for pure development speed you can't beat .
- Steve Barry
> -Original Message-
> From: Matt Liotta [mailto:[EMAIL PROTECTED]
> Sent: 24 March 2004 01:48
> To: CF-Talk
> Subject: Re: why are procedures better? (was: RE: Securing CF Apps.)
>
>
> > 1. They
Steve Nelson said:
> Just out silly curiousity, I'd love to hear the
> advantages/disadvantages between these three versions of selecting a
> recordset from a db.
>
> version 1
> -
>
> select first_name
> from users
> where user_id='#url.user_id#'
>
Thi
you think that makes a big difference. What makes one more
secure than the other?
Also, if these aren't the way to go, what's a better solution?
Steve Nelson
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 8:48 PM
To: CF-Ta
b d e s i g n
[EMAIL PROTECTED]
www.revolutionwebdesign.com
its only looks good to those who can see bad as well
-anonymous
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 8:48 PM
To: CF-Talk
Subject: Re: why are procedures better? (was: RE: Sec
esday, March 23, 2004 8:48 PM
To: CF-Talk
Subject: Re: why are procedures better? (was: RE: Securing CF Apps.)
> 1. They execute faster. The db (I only know from Oracle and SQL
> Server, if
> others are different it doesn't really concern me) can optimize the
> executio
> 1. They execute faster. The db (I only know from Oracle and SQL
> Server, if
> others are different it doesn't really concern me) can optimize the
> execution plan.
>
Prepared statements execute at the same speed as stored procedures.
> 2. You can often times do more. There are things I can
Heald, Tim wrote:
> 1. They execute faster. The db (I only know from Oracle and SQL Server, if
> others are different it doesn't really concern me) can optimize the
> execution plan.
Prepared statements have precompiled execution plans as well.
> 3. You can limit access with them. Now granted y
1. They execute faster. The db (I only know from Oracle and SQL Server, if
others are different it doesn't really concern me) can optimize the
execution plan.
2. You can often times do more. There are things I can do in a pl/sql
package/procedure that I cannot do in a query call
3. You can l
46 matches
Mail list logo
