Re: Connecting remotely - multi tier

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(at)visionforisrael(dot)com>
To: "Bob Kline" <bkline(at)rksystems(dot)com>
Cc: "Adam Lang" <aalang(at)rutgersinsurance(dot)com>;
<pgsql-interfaces(at)postgresql(dot)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(at)rksystems(dot)com
> > http://www.rksystems.com
> >
> >
>
>
>