Subject RE: [ib-support] Executing DSQL inside a stored procedure
Author Alan McDonald
It's an interesting approach to security (no judgement in that). I'm always
on the lookout for more methods of security. Pity the php scripts are so
easily "got-at". Is there not one protected place you can store your uname
and pword? It seems to make for a very long winded approach to data

-----Original Message-----
From: Jaume Andreu Sabater Malondra [mailto:jsabater@...]
Sent: Sunday, 8 September 2002 10:37
Subject: Re: [ib-support] Executing DSQL inside a stored procedure

On Sunday 08 September 2002 02:01, Alan McDonald wrote:

> you have me very curious as to why you would be trying this method of
> dynamic SQL. I'm not sure where to start...

Well, in a few words, I have a stored procedure which receives a set of
parameters and, depending of which of them are set and which not as well
depending on the values they have, the UPDATE statement that must be
is different (the WHERE condition changes).

This is not the first time I use the "methd", but previous times I used it
Oracle, about three years ago.

> AFAIK, there is no such datatype as "STATEMENT", so there's little
> why it objects to this. The prepare instruction is something a client

I have obtained all the information from Language Reference of Interbase
(the PDFs). But I was using it in a wrong way. I mean, Interbase is not
to execute DSQL inside a string in a trigger or a stored procedure, as
Todd has told me in Borland Interbase newsgroups. So, I guess the problem
the same here in Firebird.

> What I really wonder about is why you are going to so much trouble
> the statement client side, then saving it into a table column, then
> committing it then trying to execute it inside a SP... If you are
> it client side anyway, why wouldn't you just execute it from the client?

Well, I admit it may look "strange", but you have my word it deserves the
and there are good reasons behind it. I'll briefly explain it:

1. I am using Firebird from Php under Apache on my Linux server in a web

2. The database user which is used on Php scripts only have got
over a set of stored procedures.

3. These stored procedures are created to solve the needs of the whole
of pages that form the web site.

4. You want a dataset with news? You call a stored procedure from Php code
pass the necessary parameters to it (date, first and skip values, etc.).

5. The database user does not know tables exist (unless there is something
cannot do with stored procedures, like this case), so security is
and, in case the web site security is compromised and a cracker gets the
database username and password from Php scripts, the worst thing he or she
can do is execute the stored procedures.

6. This, combined with the fact that _ALL_ the stored procedures call a
"primary/basic" stored procedure (which is only readable by those stored
procedures, but not by the database user that executes the above ones)
verifies the connection is valid/registered, gives a new level of
to the web site. The cost if disk accesses are increased, of course.

> A mystery inside an enigma perhaps - I'm sure you will enlighten us...

I hope I have.

Jaume Andreu Sabater Malondra
Registered linux user #209072

"Ubi sapientas ibi libertas"

Yahoo! Groups Sponsor

To unsubscribe from this group, send an email to:

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

[Non-text portions of this message have been removed]