DB Relay - NGiNX based open source project

Server NGINX
1

DB Relay is an open source project built around the NGiNX web server
platform, providing an HTTP/JSON interface to a variety of database
servers. It enables database access without drivers and web application
development without complex middleware. Designed for operational
efficiency and ease of maintenance.

Please, visit us at http://dbrelay.com

2

On Thu, Jul 22, 2010 at 2:49 PM, Vlad D. [email protected] wrote:

DB Relay is an open source project built around the NGiNX web server platform, providing an HTTP/JSON interface to a variety of database servers. It enables database access without drivers and web application development without complex middleware. Designed for operational efficiency and ease of maintenance.

Please, visit us at http://dbrelay.com

I didn’t get a chance to check it out as OSCON… but it is a bit
scary exposing your queries directly to the client side / GET / POST /
whatever.

There’s a usability model for this, sure, but I can see a lot of stuff
it should -not- be used for…

I assume it does not allow for concatenated queries and SQL injection
characters…

3

Hi Michael,

We’re still here at OSCON if you want to stop by.

It’s intended for use in applications, so it’s really no different
than using the native database APIs vis-a-vis security, all the same
concerns apply. We just make it easier to get to the database.

Brian

2010/7/22 Michael S. [email protected]:

4

On Thu, Jul 22, 2010 at 3:09 PM, Brian B. [email protected] wrote:

Hi Michael,

We’re still here at OSCON if you want to stop by.

It’s intended for use in applications, so it’s really no different
than using the native database APIs vis-a-vis security, all the same
concerns apply. Â We just make it easier to get to the database.

Brian

Applications mask the queries though.

via PHP:

foo.php?file=1

via DBRelay:

/sql?sql=SELECT something FROM table WHERE file_id=somevariable

(of course URL encoded, blahblah)

Seems to me the model shouldn’t be used for anything that would be an
information disclosure to anything sensitive. For instance, perhaps
you want a user’s email address. well, depending on how it’s done, you
could SHOW COLUMNS FROM user; or SELECT * FROM user; instead of SELECT
email FROM user … right?

5

Hi,
I don’t want to belittle your project, but it seems that:

  1. you’ve re-implemented things already covered by ngx_drizzle (drizzle,
    mysql, sqlite) and ngx_postgres (postgresql),
  2. you did this in the blocking way, which doesn’t play nice with
    nginx,
  3. you’re exposing whole database to the public and require client-side
    scripts to have credentials to the database.

It’s great that you’re also supporting MS SQL Server (via FreeTDS), but
doing this in such fashion isn’t going to help anyone. Imagine the case
in
which n users (where n >= worker_processes) would issue “SELECT
sleep(2592000)” command. This would lock dbrelay for a month…

Best regards,
Piotr S. < [email protected] >

6

…and last but not least:

  1. you don’t protect the database against SQL injections at all.

DISCLAIMER: I’m author of ngx_postgres.

Best regards,
Piotr S. < [email protected] >

7

Hi Brian,

Yes, it is blocking currently. That will be fixed, I’ve been working
on the upstream version, just not ready yet.

Please note that just by using ngx_http_upstream_* you won’t make it
magically non-blocking, you’ll also need non-blocking C libraries
(libdrizzle for MySQL, freetds for SQL Server) and you’ll need to use
the
non-blocking interfaces (which you don’t use right now)… That means
that
for MySQL you’ll be better off by building on top of ngx_drizzle.

ngx_drizzle and ngx_postgres weren’t around at the time we started
development

Ah, OK… That would explain it :slight_smile:

(I’m looking at ways to build on them if possible since
they do now exist).

It’s almost* possible right now, to be honest you can “implement”
dbrelay
using ngx_form_input combined with ngx_drizzle/ngx_postgres.

  • almost, because by design neither ngx_drizzle nor ngx_postgres allow
    you
    to specify database login and password on the run-time.

Best regards,
Piotr S. < [email protected] >

8

Hi Piotr,

Yes, it is blocking currently. That will be fixed, I’ve been working
on the upstream version, just not ready yet.
ngx_drizzle and ngx_postgres weren’t around at the time we started
development (I’m looking at ways to build on them if possible since
they do now exist).
We aren’t really focused on providing a REST interface to the data, so
for our use case, this is exactly what was needed. Your mileage may
vary of course.

Brian

2010/7/22 Piotr S. [email protected]:

9

On Fri, Jul 23, 2010 at 6:18 AM, Piotr S. [email protected]
wrote:

It’s great that you’re also supporting MS SQL Server (via FreeTDS),

Hmm, it’ll be interesting to implement an ngx_freetds or ngx_sqlserver
module using FreeTDS and the infrastructure used by both ngx_drizzle
and ngx_postgres. I myself don’t know how well the non-blocking
support of FreeTDS is. Hopefully it does not suck as Oracle’s OCI, or
we’ll have to use internal pthreads to work around those APIs that
cannot be made non-blocking :slight_smile:

And as others have already pointed out, I’m scared to see db passwords
and raw SQL query strings appear in JavaScript code on DB Relay’s home
page. Hopefully that piece of JS is intended to run on server side
only (via the ngx_js module or V8 or something else) :wink:

Cheers,
-agentzh

P.S. I’m one of the authors of ngx_drizzle and ngx_postgres :slight_smile:

10

Hi,

FreeTDS (note, I am the original author of FreeTDS) implements the
APIs used by either Sybase or Microsoft which means dblib, ctlib, and
ODBC. ctlib has support for asynchronous communications but does not
expose the socket file descriptor to the rest of the world, but since
it’s open source that could be made to happen, it’s just not in the
API presently.

I’m interested in your thinking on using pthreads to work around the
blocking API, I’ve been using a coprocess communicating over unix
domain sockets to do the same thing (pending conversion to
non-blocking module of course).

Server-side javascript is one idea, the V8 stuff looks very
interesting. The primary use was for intranet users where the
database credentials were supplied by users, so the credentials
problem was not an issue in that context.

Brian

2010/7/31 agentzh [email protected]: