Re: Connecting remotely - multi tier - Mailing list pgsql-interfaces

I saw the light last week involving n-tier architecture.  Had a week long VB
class.  Which leads me to an important question.

Windows applications in a distributed architecture connect over RPC and
DCOM.  How would I write a Windows application to access a Linux based
middle tier?  So far the way I see it is a Windows application to a windows
server, which then connects to a linux based postgresql.  Short of something
like FTP or waiting till XML comes around more, what options do I have to go
from a windows app to a non-windows server to postgresql on a *nix server?

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Cedar Cox" <cedarc@visionforisrael.com>
To: "Bob Kline" <bkline@rksystems.com>
Cc: "Adam Lang" <aalang@rutgersinsurance.com>;
<pgsql-interfaces@postgresql.org>
Sent: Monday, November 06, 2000 4:34 AM
Subject: Re: [INTERFACES] Connecting remotely - multi tier


>
> This is my point exactly.  Our setup is a single Linux server w/ win9x
> clients.  The users, of course, have accounts on the Linux server.
> Because of our simi-open environment, I treat everything outside the
> server as the 'world', and also because client machines will eventually be
> connected through the internet or some other non-secure route.  I guess
> the issue is that the middle tier shouldn't allow anything more (as far as
> modifying data) then the front end is capable of.  The front end would
> therefore be a fairly small, limited application.  The middle tier is
> (should be) in a controlled environment whereas the front end is not.
> The front end could be modified (security bypassed, hacked).  Middle tier
> modification would require hacking of the server on which it resides
> before even getting to it, then again, the same with the backend.
>
> Basically, you want to make sure that whatever does security checks is
> itself secure.  Sounds simple, but look at it this way:  If your frontend
> does things such as check the format of new data in a field, for example,
> the user could hack or bypass the frontend in order to get incorrectly
> formatted data into a table.  (Paranoid?  Yes, that's what security is
> for..)  This may not sound like a big risk, but then again, this is not an
> extremely important check (or is it?).  The perhaps proper way would be to
> put checks like this in the backend or middle tier so that there is no way
> to bypass it.  Again, this would mean that most of your work would go into
> the backend or middle tier programming, which is perhaps to your advantage
> if you want to replace/add another frontend, less work to do.  Overall, I
> think the expandability and security benefits are worth putting work into
> a middle tier or backend programming.
>
> I don't claim to be correct as I am speaking with little experience, but
> these are the security issues I see.  Thoughts?  (..sorry if I rambled)
>
> -Cedar
>
> ... Is this thread beginning to discuss a book about database security
> that should be read?  ;)
>
>
> On Thu, 2 Nov 2000, Bob Kline wrote:
>
> > On Thu, 2 Nov 2000, Adam Lang wrote:
> >
> > > But if you are an inhouse developer and the database is only in huse
> > > and the client is only in house and the database is not open to the
> > > public, do you still have to use development time to build that
> > > "middle tier" just so you can roll out an app that uses the company
> > > database?
> >
> > Uh, weren't you the one who originally wondered out loud about the
> > danger of your users obtaining direct access to your dbms?  Even if you
> > weren't, it's not a good idea to assume there are no security issues
> > just because you're working inside an intranet.
> >
> > --
> > Bob Kline
> > mailto:bkline@rksystems.com
> > http://www.rksystems.com
> >
> >
>
>
>