> On 22 Mar 2007 14:58:15 -0700, Kev <kevinjamesfield@xxxxxxxxx> wrote: > > Hi everyone, > > > > I'm still in the design phase of a project. I was just wondering if > > anyone has any thoughts or experience on the idea of cutting the P out > > of the LAMP (or in my case, WAMP for now) stack. What I mean is > > having > > everything encapsulated into sql (or plpgsql or plperl where needed) > > functions stored in the pgsql server, and have Apache communicate with > > pgsql via a tiny C program that pretty much just checks whether the > > incoming function is on the allowed list and has the proper data > > types, > > then passes it straight in. Any errors are logged as potential > > security > > breaches. > > > > I'm really new to mod_perl too, so another question would be if this > > would be much faster than a simple perl script that did the same > > thing. > > > > I ask this because I realize I need to carefully check data coming > > into > > pgsql functions as well as at the client end. Why maintain a bunch of > > scripts with names similar to the functions they're calling and all > > performing similar checks anyway? > > > > I was kinda salivating at the thought of how fast things would be if > > you > > cut out the A as well, by using a Flash applet to give socket access > > to > > JavaScript. But then I guess you have to make your pgsql server > > itself > > publicly accessible on some port. Is that just asking for trouble? > > > > I appreciate any comments or thoughts anyone might have on this. > > IMO, I think 'thin middleware' approach is a great way to design > applications...so you are right on the money. The web server. IMO, > should be mostly concerned about rendering html. I don't think > eliminating the middleware is really practical. While you could use a > thick-client javascript framework like GWT and write your queries in > javascript (getting data back via json), I don't think it's really > possible to secure this properly without killing the 'ease of > implementation' factor. > > Then again, it's no worse then your typical old school visual basic or > delphi in-house application so common in the 90's. I really miss the > simplicity of Delphi. > > merlin Hi Merlin, Thanks for your reply, these are helpful comments. Just wondering about the security factor, though--is there something specific that would be impossible to lock down? I would think (but I'm no expert to be sure!) that a whitelist-only filter, I mean, if there weren't any buffer overflow vulnerabilities or anything like that, would be tough to sneak malicious SQL functions or other code through. Or did you mean in some other way? I don't think I would pass straight SQL queries anyway, if it makes a difference, but rather just the function name and the parameters separately, so that there's always an SQL function involved, but so that that's not obvious from the javascript end. All that's obvious is the thin-perlness of it: my perl script could be calling another script by the name we pass it, or a perl subroutine, or something else. Heh...Delphi was fun, except when I wanted to do some fancier things with it, even in high school...although our low-budget high school didn't exactly have the latest major version. Thanks, Kev
