# DB Relay - NGiNX based open source project **URL:** \ **Category:** NGINX\ **Created:** [July 22, 2010, 11:50pm UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049 "2010-07-22T23:50:55Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 22, 2010, 11:50pm UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/1 "2010-07-22T23:50:55Z")
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](http://dbrelay.com) ---
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 22, 2010, 11:59pm UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/2 "2010-07-22T23:59:07Z")
On Thu, Jul 22, 2010 at 2:49 PM, Vlad D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](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… ---
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 23, 2010, 12:09am UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/3 "2010-07-23T00:09:40Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 23, 2010, 12:21am UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/4 "2010-07-23T00:21:57Z")
On Thu, Jul 22, 2010 at 3:09 PM, Brian B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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? ---
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 23, 2010, 12:19am UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/5 "2010-07-23T00:19:02Z")
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. \< removed\_email\_address@domain.invalid \> ---
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 23, 2010, 12:23am UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/6 "2010-07-23T00:23:08Z")
…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. \< removed\_email\_address@domain.invalid \> ---
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 23, 2010, 1:01am UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/7 "2010-07-23T01:01:11Z")
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 🙂 > (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. \< [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) \> ---
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 23, 2010, 12:27am UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/8 "2010-07-23T00:27:49Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): ---
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 31, 2010, 8:39am UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/9 "2010-07-31T08:39:01Z")
On Fri, Jul 23, 2010 at 6:18 AM, Piotr S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 🙂 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) 😉 Cheers, -agentzh P.S. I’m one of the authors of ngx\_drizzle and ngx\_postgres 🙂 ---
**Author:** ![dascalvlad](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/9dc877/32.png) [@dascalvlad](https://www.ruby-forum.com/u/dascalvlad)\ **Post date:** [July 31, 2010, 3:11pm UTC](https://www.ruby-forum.com/t/db-relay-nginx-based-open-source-project/192049/10 "2010-07-31T15:11:44Z")
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 [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):