From: Adam Lang <aalang@rutgersinsurance.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Connecting remotely - multi tier
Date: Mon, 13 Nov 2000 15:17:16 -0500
Message-ID: <014501c04dae$b7bf7500$330a0a0a@6014cwpza006> (raw)
References: <Pine.LNX.4.21.0011031027420.27193-100000@nanu.visionforisrael.com>
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
> >
> >
>
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: aalang@rutgersinsurance.com
Subject: Re: Connecting remotely - multi tier
In-Reply-To: <014501c04dae$b7bf7500$330a0a0a@6014cwpza006>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox