Hi,
> but can't the developer allow literals again?
Executing the statement SET ALLOW_LITERALS should be restricted. The
application uses another user name / password and doesn't have to
access rights to enable it. Maybe the user name / password is
configured using JNDI, so the application devel
Hi,
> I fail to see how the backend could distinguish between a query sent by a
> query tool and a query sent by an "application".
The backend could use a different client library (a client library
that doesn't allow literals). But in this case two or three client
libraries are required.
Probab
Hi,
> providing a mode in which the server would reject PQexec strings containing
> more than one query.
That wouldn't help a lot. The simple SQL injection is not detected:
ResultSet rs = stat.executeQuery(
"SELECT * FROM USERS WHERE PASSWORD='" + password + "'");
An attacker would only need
Hi,
> > Wouldn't it be much simpler to have a version of the libpq client lib
> > that only understands prepared queries?
That would be possible. However the problem is not 'prepared queries'
versus 'direct queries'. It is possible to use literals in prepared
queries:
PreparedStatement prep =
On Sat, 26 Apr 2008 23:24:59 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 26, 2008 at 9:58 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > IIRC there was some discussion recently of providing a mode in
> > which the server would reject PQexec strings containing more than
> > one
On Sat, 26 Apr 2008 21:50:10 -0600
"Scott Marlowe" <[EMAIL PROTECTED]> wrote:
> Agreed. My point was that to do what the OP wants, wouldn't it make
> more sense to just lobotomize libpq so it doesn't understand
> anything but prepared queries. Doesn't obviate the need for a
> client side languag
On Sun, 27 Apr 2008 12:38:48 +0200
Ivan Sergio Borgonovo <[EMAIL PROTECTED]> wrote:
> Once you've developers that are so patient to write stuff like:
>
> "select a.id, b.name from a join b on b.id=a.id where
> a.status='pending' and b.id>7 and b.status='logged'"
>
> into
>
> "select a.id, b.nam
In another thread, the O.P. had a question about a large table with over 100
columns. Is this usual? Whenever I make a database, which is not often, it
ends up with tables that rarely have over to columns, and usually less than
that. When normalized, my tables rarely get very wide.
Without critici
Jean-David Beyer wrote:
In another thread, the O.P. had a question about a large table with over 100
columns. Is this usual? Whenever I make a database, which is not often, it
ends up with tables that rarely have over to columns, and usually less than
that. When normalized, my tables rarely get v
On Sun, Apr 27, 2008 at 9:01 AM, Jean-David Beyer
<[EMAIL PROTECTED]> wrote:
> In another thread, the O.P. had a question about a large table with over 100
> columns. Is this usual? Whenever I make a database, which is not often, it
> ends up with tables that rarely have over to columns, and usua
Any chance this could be a view?
On Sun, Apr 27, 2008 at 12:06 PM, Jonah H. Harris <[EMAIL PROTECTED]>
wrote:
> On Sun, Apr 27, 2008 at 9:01 AM, Jean-David Beyer
> <[EMAIL PROTECTED]> wrote:
> > In another thread, the O.P. had a question about a large table with over
> 100
> > columns. Is this
Ivan Sergio Borgonovo wrote:
It'd be nice to have a wrapper that let you write prepared statements
this way:
"select a.id, b.name from a join b on a.id=b.id where
a.status=$variable1 and b.id>$variable2 etc... but that's a pretty
good change to any language parser.
Python already supports s
On Sun, 27 Apr 2008 11:55:18 -0400
Joe <[EMAIL PROTECTED]> wrote:
> Ivan Sergio Borgonovo wrote:
> > It'd be nice to have a wrapper that let you write prepared
> > statements this way:
> >
> > "select a.id, b.name from a join b on a.id=b.id where
> > a.status=$variable1 and b.id>$variable2 etc...
Hi,
> The problem may be legacy code.
Of course. There is a lot of legacy code that needs to be made secure
('hardened'). The best solution is to use parameterized queries. To
find out what statements are still not doing that, first disable text
literals only. If some places are incorrect, the r
Ivan Sergio Borgonovo wrote:
That's better than nothing but it is still a lot of code duplication.
You've to write column names in the sql statement and in the array
and... column values are not contextual to the statement.
The apparent duplication in the example stems for its tutorial natur
have several schemae, each with identical tables.
in create scripts have been taking great care to fully qualify, eg,
col1 references schema1.tab1( col1 )
however, just got burnt big time on sequences! need to qualify them as
well, eg
col1 integer default nextval( 'schema1.seq1' )
\dt is no
chester c young <[EMAIL PROTECTED]> writes:
> however, just got burnt big time on sequences! need to qualify them as
> well, eg
> col1 integer default nextval( 'schema1.seq1' )
Move to something newer than 8.0.x, and this is automatic (because
nextval's argument is actually a regclass constant)
> > however, just got burnt big time on sequences! need to qualify
> them as
> > well, eg
> > col1 integer default nextval( 'schema1.seq1' )
>
> Move to something newer than 8.0.x, and this is automatic (because
> nextval's argument is actually a regclass constant).
>
>
18 matches
Mail list logo
