Re: Connecting remotely - multi tier

Ok... so if I am writing a distributed application in windows that will use
a Postgresql backend, I should have the client interface another "server"
application, which will inturn access/retrieve informaton from the database?

Well, how about this... I have a VB client application that uses a NT server
VB application for the middle tier, and the postgresql database is on a
linux server.  Is it ok THEN to wrap the libpq into a dll and COM object for
the middle tier to access the database, as oppsoed to using ODBC?

In essence that is what I was asking... the possibility a Postgresql API
that I could use, as opposed to a generalised ODBC driver.  Whether for a
client or a middle tier, it doesn't matter.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar>
To: <cedarc@visionforisrael.com>; <pgsql-interfaces@postgresql.org>
Sent: Thursday, November 02, 2000 10:03 AM
Subject: Re: [INTERFACES] Connecting remotely - multi tier


> Cedar Cox <cedarc@visionforisrael.com> el día Thu, 2 Nov 2000 17:18:48
+0200
> (IST), escribió:
>
> >You seem to have given this a lot of thought so let me ask a question.
> >How do I implement a user login system?  If the user knows their password
> >(and don't they always?..), what's to stop them from finding and
> >contacting the database directly, bypassing the middle tier?
>
> because you setup the database (ie. pg_hba.conf) so that ONLY and only
> the machine thas has the middle tier can connect to the database directly,
> no other machine in the world can conect to the databse bypassing the
> middle tier (even if the user know all passwords).
>
> >  I haven't
> >been able to find a solution to this problem.  Every time I try to think
> >about it by brain goes into a recursive loop!  :o
>
> this is what I've done:
>
> I implemented a login system with php (using http authentication),
> so the machine running apache and php (the only machine with direct
> access to the db) connect with with the db with the username & password
> in behalf of the user.
>
> this is my routine:
>
> function sak_db_auth()
> {
>   global $db_conf;
>   global $PHP_AUTH_USER;
>   global $PHP_AUTH_PW;
>
> //  header("Cache-Control: no-cache");
> //  header("Pragma: no-cache");
>   header("Expires: Sat, Jan 01 2000 01:01:01 GMT");
>
>   function login_prompt()
>   {
>     global $db_conf;
>     header("WWW-Authenticate: Basic realm=\"" . $db_conf["realm"] . "\"");
>     header("HTTP/1.0 401 Unauthorized");
>     echo "<meta HTTP-EQUIV=\"Refresh\" CONTENT=\"0; URL=" .
> $db_conf["url_on_cancel"] . "\">";
>     exit;
>   }
>
>   if (!isset($PHP_AUTH_USER)) {
>     login_prompt();
>   } else
>   {
>     if($PHP_AUTH_USER && $PHP_AUTH_PW)
>     {
>       if (!in_array($PHP_AUTH_USER, $db_conf["allowed_users"]))
>       {
>         return(false);
>       }
>
>       $db_conf["user"] = $PHP_AUTH_USER;
>       $db_conf["password"] = $PHP_AUTH_PW;
>       $db_conf["str_conn"] = "dbname=" . $db_conf["dbname"] . " user=" .
> $db_conf["user"] . " password=" . $db_conf["password"];
>
>       $db = @pg_connect($db_conf["str_conn"]);
>
>       if (!$db) {
>         $result = false;
>       } else {
>         pg_close($db);
>         $result = true;
>       }
>     }
>   }
>   return($result);
> }
>
> in this way the users cannot connect directly to the db with crap
> like access, excel and so on ..
>
> >On Wed, 1 Nov 2000, Sergio A. Kessler wrote:
> >
> >> "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 2000
09:52:35
> >> -0500, escribió:
> >>
> >> [...]
> >> >
> >> >What are people's thoughts?
> >>
> >> people's thoughts are that you really want to design a multi-thier
> >> design (for example a 3 layer design), where
> >>
> >>                                             /  client1 (browser)
> >>  database  <--->   bussines rules           -  client2 (browser)
> >>                   (ie. apache, php,...)     \  .....
> >>
> >>
> >> if your client has direct access to the database, you design is
broken...
> >>
> >> sergio
> >>
> >>