Обсуждение: Connecting remotely.
This may be a silly question, but how does *nix systems speak to a remote database without ODBC, like Windows? As an example, PHP... I have Apache/PHP on one server, and the database on another. How does it do remote calls? Adam Lang Systems Engineer Rutgers Casualty Insurance Company
On Wed, Nov 01, 2000 at 09:29:47AM -0500, Adam Lang wrote:
> This may be a silly question, but how does *nix systems speak to a remote
> database without ODBC, like Windows?
Database's client side libraries take care of that. But that
means linking your app with some particular database library.
e.g. PHP has php_pgsql, php_sybase... if you want your
app to be database-agnostic, you can link it with e.g. UnixODBC,
which should do the database-specific work.
> As an example, PHP... I have Apache/PHP on one server, and the database on
> another. How does it do remote calls?
$db = pg_connect("host=another.net port=5432 ... ");
--
marko
That's what I was figuring... so... is it possible to take those files,
compile them into a dll and make a postgresql-specific remote connection
library? So, say instead of referencing ADO in Visual Basic and using the
ODBC driver, merely wrap up necessary functionality of the client side
libraries? Would that be hard? (Never made a DLL before, so unsure).
Granted it breaks the idea of writing code to use on any database, but if
you are making an in-house application and have control over the database...
Also, it wouldn't help Access oriented people, but this would be used for a
bit more hard core integration, something that if you want, you shouldn't be
using Access for a front end anyway.
What are people's thoughts?
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Marko Kreen" <marko@l-t.ee>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 9:50 AM
Subject: Re: [INTERFACES] Connecting remotely.
> On Wed, Nov 01, 2000 at 09:29:47AM -0500, Adam Lang wrote:
> > This may be a silly question, but how does *nix systems speak to a
remote
> > database without ODBC, like Windows?
>
> Database's client side libraries take care of that. But that
> means linking your app with some particular database library.
> e.g. PHP has php_pgsql, php_sybase... if you want your
> app to be database-agnostic, you can link it with e.g. UnixODBC,
> which should do the database-specific work.
>
> > As an example, PHP... I have Apache/PHP on one server, and the database
on
> > another. How does it do remote calls?
>
> $db = pg_connect("host=another.net port=5432 ... ");
>
> --
> marko
Yes, you can build libpq into libpq.dll. You can then add the function
declarations at the top, much like you would for an API call. Alternatively
you could wrap a COM object around the DLL and use it that way.
Joel
-----Original Message-----
From: Adam Lang [mailto:aalang@rutgersinsurance.com]
Sent: Wednesday, November 01, 2000 9:53 AM
Cc: pgsql-interfaces
Subject: Re: [INTERFACES] Connecting remotely.
That's what I was figuring... so... is it possible to take those files,
compile them into a dll and make a postgresql-specific remote connection
library? So, say instead of referencing ADO in Visual Basic and using the
ODBC driver, merely wrap up necessary functionality of the client side
libraries? Would that be hard? (Never made a DLL before, so unsure).
Granted it breaks the idea of writing code to use on any database, but if
you are making an in-house application and have control over the database...
Also, it wouldn't help Access oriented people, but this would be used for a
bit more hard core integration, something that if you want, you shouldn't be
using Access for a front end anyway.
What are people's thoughts?
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Marko Kreen" <marko@l-t.ee>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 9:50 AM
Subject: Re: [INTERFACES] Connecting remotely.
> On Wed, Nov 01, 2000 at 09:29:47AM -0500, Adam Lang wrote:
> > This may be a silly question, but how does *nix systems speak to a
remote
> > database without ODBC, like Windows?
>
> Database's client side libraries take care of that. But that
> means linking your app with some particular database library.
> e.g. PHP has php_pgsql, php_sybase... if you want your
> app to be database-agnostic, you can link it with e.g. UnixODBC,
> which should do the database-specific work.
>
> > As an example, PHP... I have Apache/PHP on one server, and the database
on
> > another. How does it do remote calls?
>
> $db = pg_connect("host=another.net port=5432 ... ");
>
> --
> marko
> -----Original Message----- > From: Adam Lang [mailto:aalang@rutgersinsurance.com] > Sent: 01 November 2000 14:53 > Cc: pgsql-interfaces > Subject: Re: [INTERFACES] Connecting remotely. > > > That's what I was figuring... so... is it possible to take > those files, > compile them into a dll and make a postgresql-specific remote > connection > library? So, say instead of referencing ADO in Visual Basic > and using the > ODBC driver, merely wrap up necessary functionality of the client side > libraries? Would that be hard? (Never made a DLL before, so unsure). Many before you have tried this and failed miserably!! :-) Seriously though, I think you would be creating a horrendous amount of work for yourself (having considered the idea for 18 months or so myself). IMHO time would be far better spent writing an OLEDB provider for PostgreSQL (a native one, not one using the Simple Provider interface). At least then you can still manipulate data in recordset objects which aren't really that bad to work with and are very useful when you attach them to a hidden data control so you can bind other controls to them. Regards, Dave.
"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
Well, I was mostly feeling out ideas... mainly because I don't know how to write com objects or an OLE DB provider. :P The 6th through the 10th I have a training course for VB and it gets into Active X DLLs and Com objects, so naturally I was thinking of what I would use my new found power for and I thought of that as a possibility. As for the ole db... does anyone have an idea where to start looking for that info? Would it have to be written in C? I found a company that sells software that creates ole dbs... Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Dave Page" <dpage@vale-housing.co.uk> To: "'Adam Lang'" <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org> Sent: Wednesday, November 01, 2000 10:32 AM Subject: RE: [INTERFACES] Connecting remotely. > > > > -----Original Message----- > > From: Adam Lang [mailto:aalang@rutgersinsurance.com] > > Sent: 01 November 2000 14:53 > > Cc: pgsql-interfaces > > Subject: Re: [INTERFACES] Connecting remotely. > > > > > > That's what I was figuring... so... is it possible to take > > those files, > > compile them into a dll and make a postgresql-specific remote > > connection > > library? So, say instead of referencing ADO in Visual Basic > > and using the > > ODBC driver, merely wrap up necessary functionality of the client side > > libraries? Would that be hard? (Never made a DLL before, so unsure). > > Many before you have tried this and failed miserably!! :-) > > Seriously though, I think you would be creating a horrendous amount of work > for yourself (having considered the idea for 18 months or so myself). IMHO > time would be far better spent writing an OLEDB provider for PostgreSQL (a > native one, not one using the Simple Provider interface). At least then you > can still manipulate data in recordset objects which aren't really that bad > to work with and are very useful when you attach them to a hidden data > control so you can bind other controls to them. > > Regards, > Dave.
That's sort of what I was thinking... Make a reference to it and use it much
like regobj.dll for modifying Registry in windows...
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Clark, Joel" <jclark@lendingtree.com>
To: "'Adam Lang'" <aalang@rutgersinsurance.com>
Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 10:35 AM
Subject: RE: [INTERFACES] Connecting remotely.
> Yes, you can build libpq into libpq.dll. You can then add the function
> declarations at the top, much like you would for an API call.
Alternatively
> you could wrap a COM object around the DLL and use it that way.
>
> Joel
>
> -----Original Message-----
> From: Adam Lang [mailto:aalang@rutgersinsurance.com]
> Sent: Wednesday, November 01, 2000 9:53 AM
> Cc: pgsql-interfaces
> Subject: Re: [INTERFACES] Connecting remotely.
>
>
> That's what I was figuring... so... is it possible to take those files,
> compile them into a dll and make a postgresql-specific remote connection
> library? So, say instead of referencing ADO in Visual Basic and using the
> ODBC driver, merely wrap up necessary functionality of the client side
> libraries? Would that be hard? (Never made a DLL before, so unsure).
> Granted it breaks the idea of writing code to use on any database, but if
> you are making an in-house application and have control over the
database...
> Also, it wouldn't help Access oriented people, but this would be used for
a
> bit more hard core integration, something that if you want, you shouldn't
be
> using Access for a front end anyway.
>
> What are people's thoughts?
>
> Adam Lang
> Systems Engineer
> Rutgers Casualty Insurance Company
> ----- Original Message -----
> From: "Marko Kreen" <marko@l-t.ee>
> To: "Adam Lang" <aalang@rutgersinsurance.com>
> Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>
> Sent: Wednesday, November 01, 2000 9:50 AM
> Subject: Re: [INTERFACES] Connecting remotely.
>
>
> > On Wed, Nov 01, 2000 at 09:29:47AM -0500, Adam Lang wrote:
> > > This may be a silly question, but how does *nix systems speak to a
> remote
> > > database without ODBC, like Windows?
> >
> > Database's client side libraries take care of that. But that
> > means linking your app with some particular database library.
> > e.g. PHP has php_pgsql, php_sybase... if you want your
> > app to be database-agnostic, you can link it with e.g. UnixODBC,
> > which should do the database-specific work.
> >
> > > As an example, PHP... I have Apache/PHP on one server, and the
database
> on
> > > another. How does it do remote calls?
> >
> > $db = pg_connect("host=another.net port=5432 ... ");
> >
> > --
> > marko
What's the difference between having the client use ADO to talk to the database as opposed to an interface using the postgresql client libraries? Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar> To: <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org> Sent: Wednesday, November 01, 2000 11:18 AM Subject: Re: [INTERFACES] Connecting remotely. > "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
> As for the ole db... does anyone have an idea where to start > looking for that info? http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/oled0c s7.htm > Would it have to be written in C? I found a > company that sells > software that creates ole dbs... It shuold be possible to write it in any language that can produce COM objects which support the OLE-DB interfaces (there are lots of them). C++ is probably the most common langauge used, but there are examples in Java and Visual Basic as well (samples available at http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/osp298 xb.htm). //Magnus
> -----Original Message----- > From: Adam Lang [mailto:aalang@rutgersinsurance.com] > Sent: 01 November 2000 16:40 > To: pgsql-interfaces@postgresql.org > Subject: Re: [INTERFACES] Connecting remotely. > > > What's the difference between having the client use ADO to talk to the > database as opposed to an interface using the postgresql > client libraries? > Nothing, I would say. In my mind, Sergio is saying that any app written with libpq or libpq++ or any other interface that doesn't include some kind of middleware is broken. Surely that would include psql, pgAccess, pgAdmin, anything using ODBC written in C or VB or C++? Or have I missed the point completely? Regards, Dave. > > > "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 >
So in other words I should have a client that talks to a server application, which in turn talks to the database? Again, this n-tier stuff is nice if the person writing the app has to do it independent of a back end, but when you are writing for a specific instances, all it seems to do is make things harder... Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Dave Page" <dpage@vale-housing.co.uk> To: "'Adam Lang'" <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org> Sent: Wednesday, November 01, 2000 12:15 PM Subject: RE: [INTERFACES] Connecting remotely. > > > > -----Original Message----- > > From: Adam Lang [mailto:aalang@rutgersinsurance.com] > > Sent: 01 November 2000 16:40 > > To: pgsql-interfaces@postgresql.org > > Subject: Re: [INTERFACES] Connecting remotely. > > > > > > What's the difference between having the client use ADO to talk to the > > database as opposed to an interface using the postgresql > > client libraries? > > > > Nothing, I would say. In my mind, Sergio is saying that any app written with > libpq or libpq++ or any other interface that doesn't include some kind of > middleware is broken. Surely that would include psql, pgAccess, pgAdmin, > anything using ODBC written in C or VB or C++? > > Or have I missed the point completely? > > Regards, > Dave. > > > > > > "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 > >
For single tier access to pg via libpq.dll check out the following: http://www.zeos.dn.ua/eng/zeos_zdo_main.html Ken At 13:24 11/01/2000 -0500, Adam Lang wrote: >So in other words I should have a client that talks to a server application, >which in turn talks to the database? > >Again, this n-tier stuff is nice if the person writing the app has to do it >independent of a back end, but when you are writing for a specific >instances, all it seems to do is make things harder... > >Adam Lang >Systems Engineer >Rutgers Casualty Insurance Company >----- Original Message ----- >From: "Dave Page" <dpage@vale-housing.co.uk> >To: "'Adam Lang'" <aalang@rutgersinsurance.com>; ><pgsql-interfaces@postgresql.org> >Sent: Wednesday, November 01, 2000 12:15 PM >Subject: RE: [INTERFACES] Connecting remotely. > > >> >> >> > -----Original Message----- >> > From: Adam Lang [mailto:aalang@rutgersinsurance.com] >> > Sent: 01 November 2000 16:40 >> > To: pgsql-interfaces@postgresql.org >> > Subject: Re: [INTERFACES] Connecting remotely. >> > >> > >> > What's the difference between having the client use ADO to talk to the >> > database as opposed to an interface using the postgresql >> > client libraries? >> > >> >> Nothing, I would say. In my mind, Sergio is saying that any app written >with >> libpq or libpq++ or any other interface that doesn't include some kind of >> middleware is broken. Surely that would include psql, pgAccess, pgAdmin, >> anything using ODBC written in C or VB or C++? >> >> Or have I missed the point completely? >> >> Regards, >> Dave. >> >> > >> > > "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 >> > >
One layer of abstraction... If you use ADO you gain some portability across backends (limited, but still enough to warrant its investigation). If you code to libpq.dll, then not only is the SQL PG specific, but the connection libraries as well. Joel -----Original Message----- From: Adam Lang [mailto:aalang@rutgersinsurance.com] Sent: Wednesday, November 01, 2000 11:40 AM To: pgsql-interfaces@postgresql.org Subject: Re: [INTERFACES] Connecting remotely. What's the difference between having the client use ADO to talk to the database as opposed to an interface using the postgresql client libraries? Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar> To: <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org> Sent: Wednesday, November 01, 2000 11:18 AM Subject: Re: [INTERFACES] Connecting remotely. > "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
That I am aware of. But my point is that if I am not concerned with the application interfacing on other than postgres, it isn't an issue, correct? Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Clark, Joel" <jclark@lendingtree.com> To: "'Adam Lang'" <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org> Sent: Wednesday, November 01, 2000 3:14 PM Subject: RE: [INTERFACES] Connecting remotely. > One layer of abstraction... > > If you use ADO you gain some portability across backends (limited, but still > enough to warrant its investigation). If you code to libpq.dll, then not > only is the SQL PG specific, but the connection libraries as well. > > Joel > > -----Original Message----- > From: Adam Lang [mailto:aalang@rutgersinsurance.com] > Sent: Wednesday, November 01, 2000 11:40 AM > To: pgsql-interfaces@postgresql.org > Subject: Re: [INTERFACES] Connecting remotely. > > > What's the difference between having the client use ADO to talk to the > database as opposed to an interface using the postgresql client libraries? > > Adam Lang > Systems Engineer > Rutgers Casualty Insurance Company > ----- Original Message ----- > From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar> > To: <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org> > Sent: Wednesday, November 01, 2000 11:18 AM > Subject: Re: [INTERFACES] Connecting remotely. > > > > "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
I have created a project on greatbridge's site (www.greatbridge.org) to do just that (assuming life doesn't get in the way). I have not started yet, so I can't really give specifics. It will be written C++ (MS Visual C++ 6 to be exact, since that is what I have) using MS's SDK (downloadable from MSDN). Joel -----Original Message----- From: Magnus Hagander [mailto:mha@sollentuna.net] Sent: Wednesday, November 01, 2000 12:12 PM To: 'Adam Lang'; pgsql-interfaces Subject: RE: [INTERFACES] Connecting remotely. > As for the ole db... does anyone have an idea where to start > looking for that info? http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/oled0c s7.htm > Would it have to be written in C? I found a > company that sells > software that creates ole dbs... It shuold be possible to write it in any language that can produce COM objects which support the OLE-DB interfaces (there are lots of them). C++ is probably the most common langauge used, but there are examples in Java and Visual Basic as well (samples available at http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/osp298 xb.htm). //Magnus
So you are writing an OLE DB provider? I'm going to have to set up an altar to you at my house... ;) I know it may be a stupid question, but are they overly hard? I mean, if you have a lot of connectivity code already existent in the ODBC and libpq, does it make the job a lot easier? Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Clark, Joel" <jclark@lendingtree.com> To: "'Magnus Hagander'" <mha@sollentuna.net>; "'Adam Lang'" <aalang@rutgersinsurance.com>; "pgsql-interfaces" <pgsql-interfaces@postgresql.org> Sent: Wednesday, November 01, 2000 3:31 PM Subject: RE: [INTERFACES] Connecting remotely. > I have created a project on greatbridge's site (www.greatbridge.org) to do > just that (assuming life doesn't get in the way). I have not started yet, > so I can't really give specifics. It will be written C++ (MS Visual C++ 6 > to be exact, since that is what I have) using MS's SDK (downloadable from > MSDN). > > Joel > > -----Original Message----- > From: Magnus Hagander [mailto:mha@sollentuna.net] > Sent: Wednesday, November 01, 2000 12:12 PM > To: 'Adam Lang'; pgsql-interfaces > Subject: RE: [INTERFACES] Connecting remotely. > > > > As for the ole db... does anyone have an idea where to start > > looking for that info? > http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/oled0c > s7.htm > > > Would it have to be written in C? I found a > > company that sells > > software that creates ole dbs... > It shuold be possible to write it in any language that can produce COM > objects which support the OLE-DB interfaces (there are lots of them). C++ is > probably the most common langauge used, but there are examples in Java and > Visual Basic as well (samples available at > http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/osp298 > xb.htm). > > //Magnus
After consulting MSDN, I am pretty sure that I will be able to wrap the provider around libpq. If not, I won't be completing the provider. *g* The only task I have listed for my project so far is building a strategy...included in this is a feasability check. No need for altars, but testers/documenters might come in handy if I ever get something up and running. :) Joel -----Original Message----- From: Adam Lang [mailto:aalang@rutgersinsurance.com] Sent: Wednesday, November 01, 2000 3:52 PM To: pgsql-interfaces Subject: Re: [INTERFACES] Connecting remotely. So you are writing an OLE DB provider? I'm going to have to set up an altar to you at my house... ;) I know it may be a stupid question, but are they overly hard? I mean, if you have a lot of connectivity code already existent in the ODBC and libpq, does it make the job a lot easier? Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Clark, Joel" <jclark@lendingtree.com> To: "'Magnus Hagander'" <mha@sollentuna.net>; "'Adam Lang'" <aalang@rutgersinsurance.com>; "pgsql-interfaces" <pgsql-interfaces@postgresql.org> Sent: Wednesday, November 01, 2000 3:31 PM Subject: RE: [INTERFACES] Connecting remotely. > I have created a project on greatbridge's site (www.greatbridge.org) to do > just that (assuming life doesn't get in the way). I have not started yet, > so I can't really give specifics. It will be written C++ (MS Visual C++ 6 > to be exact, since that is what I have) using MS's SDK (downloadable from > MSDN). > > Joel > > -----Original Message----- > From: Magnus Hagander [mailto:mha@sollentuna.net] > Sent: Wednesday, November 01, 2000 12:12 PM > To: 'Adam Lang'; pgsql-interfaces > Subject: RE: [INTERFACES] Connecting remotely. > > > > As for the ole db... does anyone have an idea where to start > > looking for that info? > http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/oled0c > s7.htm > > > Would it have to be written in C? I found a > > company that sells > > software that creates ole dbs... > It shuold be possible to write it in any language that can produce COM > objects which support the OLE-DB interfaces (there are lots of them). C++ is > probably the most common langauge used, but there are examples in Java and > Visual Basic as well (samples available at > http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/osp298 > xb.htm). > > //Magnus
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? 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 Ideas? -Cedar 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 > >
Hi all, I'm new to this mailing list, so apologies up front if I commit a faux pas. In general, the database will reside on a different machine from the web server, and will not allow access from any machines other than some internal ones. Also, the login to the system should not be the same as the login to the database. The middle tier has a different login to handle that. If you want to avoid allowing the user to connect directly to the middle tier and use it in unexpected ways, one option would be to use serialized object communication between an applet (as the front end) and a servlet (as the middle tier). You can then put encryption and other features into your objects to further restrict user access. Hope that helps! Greg Speegle Baylor University Cedar Cox wrote: > 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? 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 > > Ideas? > > -Cedar > > 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 > > > >
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
>>
>>
On Thu, 2 Nov 2000, Cedar Cox wrote: > > 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? 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 > > Ideas? The solution is decoupling your application's security from that imposed by the DBMS. -- Bob Kline mailto:bkline@rksystems.com http://www.rksystems.com
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
> >>
> >>
> 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. That was your original question, and the answer is simply, use libpq.dll This *is* the PostgreSQL API. If your windoze client app uses libpq.dll then you can access a PostgreSQL database directly *without* the use of ODBC. The Zeos components wrap up this functionality quite nicely for Delphi. I don't know anything about using a .dll in VB so I can't help there, but that is just a general VB issue that any experienced VB'er can answer. Ken
I know how to use a dll for VB, I just didn't know if there was a way to directly access the postgresql without using ODBC. Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Ken J. Wright" <ken@ori-ind.com> To: "Adam Lang" <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org> Sent: Thursday, November 02, 2000 12:07 PM Subject: Re: [INTERFACES] Connecting remotely - multi tier > > 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. > > That was your original question, and the answer is simply, use libpq.dll This > *is* the PostgreSQL API. If your windoze client app uses libpq.dll then you can > access a PostgreSQL database directly *without* the use of ODBC. The Zeos > components wrap up this functionality quite nicely for Delphi. I don't know > anything about using a .dll in VB so I can't help there, but that is just a > general VB issue that any experienced VB'er can answer. > > Ken
yes, there is a way, download the zeos components and steal the .dll for your use ... (I don't have the url handy rigth now) "Adam Lang" <aalang@rutgersinsurance.com> el día Thu, 2 Nov 2000 13:07:24 -0500, escribió: >I know how to use a dll for VB, I just didn't know if there was a way to >directly access the postgresql without using ODBC.