Обсуждение: Re: Connecting remotely - multi tier
Adam Lang wrote: > 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? I'd like to know if this kind of layering is mandatory or not. Is it really unacceptable to expose the Posgresql backend to the rest of the world? Is there anything that I should be aware of if I let the clients to talk to the backend directly. regards, abe
as I see it, there are two reasons. Independence and security. It is more secure because you are treating the "middle tier" as a proxy server for your data. If you can control the physical connections to your database, it will be naturally more secure than if anyone can try to open a port on the server. As for independence, it makes it less painful if you change a component of your setup. Say for some reason Postgresql makes everyone pay a 10K license to use their product and you decide to change SQL servers. Instead of recoding your client piece to talk to a new database, you only need to recode your middle tier to talk to a new database server. That way, you update only a handful of installs as opposed to hundreds or thousands of client installs. For the most part I compare it to object oriented programming. Fundamentally it is a better way to program, but you aren't forced to do it that way either. Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "keke abe" <keke@mac.com> To: <pgsql-interfaces@postgresql.org> Sent: Thursday, November 02, 2000 2:03 PM Subject: Re: [INTERFACES] Connecting remotely - multi tier > Adam Lang wrote: > > > 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? > > I'd like to know if this kind of layering is mandatory or not. Is it really > unacceptable to expose the Posgresql backend to the rest of the world? Is > there anything that I should be aware of if I let the clients to talk to > the backend directly. > > regards, > abe
keke abe wrote: > Adam Lang wrote: > > > 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? > > I'd like to know if this kind of layering is mandatory or not. Is it really > unacceptable to expose the Posgresql backend to the rest of the world? Is > there anything that I should be aware of if I let the clients to talk to > the backend directly. > > regards, > abe I'd say it is mandatory. You are opening yourself up as an easy target for hackers if they can go directly to your database. Think about it. If any hole in the database security is discovered, then your goose is cooked right away. Getting the database off the web and behind a firewall should be the least you do. That gives you two levels of protection -- the firewall and the database. Plus, on the postgresql side, it is much easier to have one restricted user account from one specific machine than to try to manage thousands of dynamically created accounts. Just my opinion, of course. Greg Speegle
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? Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Greg Speegle" <Greg@10happythings.com> To: <pgsql-interfaces@postgresql.org> Sent: Thursday, November 02, 2000 2:42 PM Subject: Re: [INTERFACES] Connecting remotely - multi tier > > > keke abe wrote: > > > Adam Lang wrote: > > > > > 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? > > > > I'd like to know if this kind of layering is mandatory or not. Is it really > > unacceptable to expose the Posgresql backend to the rest of the world? Is > > there anything that I should be aware of if I let the clients to talk to > > the backend directly. > > > > regards, > > abe > > I'd say it is mandatory. You are opening yourself up as an easy target for > hackers if they can go directly to your database. Think about it. If any > hole in the database security is discovered, then your goose is cooked > right away. Getting the database off the web and behind a firewall should > be the least you do. That gives you two levels of protection -- the firewall > and the database. > > Plus, on the postgresql side, it is much easier to have one restricted user > account from one specific machine than to try to manage thousands of > dynamically created accounts. > > Just my opinion, of course. > > Greg Speegle >
Good point. I should know better than to say anything has to be done a particular way, as there will always be different environments with different requirements. However, I would always be reluctant to expose the database to the world if it contained anything important. Greg Speegle 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? > > Adam Lang > Systems Engineer > Rutgers Casualty Insurance Company > ----- Original Message ----- > From: "Greg Speegle" <Greg@10happythings.com> > To: <pgsql-interfaces@postgresql.org> > Sent: Thursday, November 02, 2000 2:42 PM > Subject: Re: [INTERFACES] Connecting remotely - multi tier > > > > > > > keke abe wrote: > > > > > Adam Lang wrote: > > > > > > > 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? > > > > > > I'd like to know if this kind of layering is mandatory or not. Is it > really > > > unacceptable to expose the Posgresql backend to the rest of the world? > Is > > > there anything that I should be aware of if I let the clients to talk to > > > the backend directly. > > > > > > regards, > > > abe > > > > I'd say it is mandatory. You are opening yourself up as an easy target for > > hackers if they can go directly to your database. Think about it. If any > > hole in the database security is discovered, then your goose is cooked > > right away. Getting the database off the web and behind a firewall should > > be the least you do. That gives you two levels of protection -- the > firewall > > and the database. > > > > Plus, on the postgresql side, it is much easier to have one restricted > user > > account from one specific machine than to try to manage thousands of > > dynamically created accounts. > > > > Just my opinion, of course. > > > > Greg Speegle > >
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
keke abe <keke@mac.com> el día Fri, 3 Nov 2000 04:03:02 +0900, escribió: >Adam Lang wrote: > >> 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? > >I'd like to know if this kind of layering is mandatory or not. Is it really >unacceptable to expose the Posgresql backend to the rest of the world? unacceptable /for me/. >Is >there anything that I should be aware of if I let the clients to talk to >the backend directly. security and integrity come to mind, but, of course, is up to you, for me, this things are really important, wich may not be the case for you ... sergio
Sergio A. Kessler wrote: > >Is there anything that I should be aware of if I let the clients to > >talk to the backend directly. > > security and integrity come to mind, but, of course, is up to you, > for me, this things are really important, wich may not be the case > for you ... I think security is important for most of us most of the time... Is there anything that I should be aware of if I let the clients to talk to the backend directly? I mean, security-wise? regards, abe
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 > >
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 > > > > > > >
Today, in a message to pgsql-interfaces, Adam Lang wrote: > > Windows applications in a distributed architecture connect over RPC > and DCOM. If you use CORBA instead of DCOM you can easily communicate between Windows and Linux/UNIX hosts. > or waiting till XML comes around more, XML is already everywhere, even Microsoft has XML support. But XML is just a document format, not a communication protocol, hence even if you use XML you still need to decide what protocol you use to move XML from host to host. Joachim -- work: joachima@realtimeint.com (http://www.realtimeint.com) private: joachim@kraut.ca (http://www.kraut.ca)
On Mon, 13 Nov 2000, Adam Lang wrote: > 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? Hopefully it is self-evident that each component of the Windows architecture was designed to only work with other components of the Windows archictecture. That was the entire point of the Windows platform. I would think that a VB program can still be written to open a TCP socket and send and receive data over it. You could design your own front-end <-> middle-tier protocol to run over it. But that is a lot of work. More suitable for simply front-end apps. Or you could go with Java. They have definitions and libraries for all the inter-layer communication you could ever want. At the end of the day, it will actually run on anything too. Or you could go completely web-based. The browser is the front-end and uses HTTP to the middle tier. > Adam Lang > Systems Engineer > Rutgers Casualty Insurance Company Tom
Yes, it is possible to open TCP sockets and do my own low level protocols, but I was hoping there would be a MUCH easier way of doing that. As for Java, great idea and all, but when you already know VB and enjoy it, don't feel like dropping languages (again). Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Tom Samplonius" <tom@sdf.com> To: "Adam Lang" <aalang@rutgersinsurance.com> Cc: <pgsql-interfaces@postgresql.org> Sent: Monday, November 13, 2000 3:20 PM Subject: Re: [INTERFACES] Connecting remotely - multi tier > > On Mon, 13 Nov 2000, Adam Lang wrote: > > > 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? > > Hopefully it is self-evident that each component of the Windows > architecture was designed to only work with other components of the > Windows archictecture. That was the entire point of the Windows platform. > > I would think that a VB program can still be written to open a TCP > socket and send and receive data over it. You could design your own > front-end <-> middle-tier protocol to run over it. But that is a lot of > work. More suitable for simply front-end apps. > > Or you could go with Java. They have definitions and libraries for all > the inter-layer communication you could ever want. At the end of the day, > it will actually run on anything too. > > Or you could go completely web-based. The browser is the front-end and > uses HTTP to the middle tier. > > > Adam Lang > > Systems Engineer > > Rutgers Casualty Insurance Company > > Tom
Corba? Hmmm. Will have to look into it. As for XML.... Microsoft has been plans on using it for multi-plaform communication. This is their idea in a nutshell. Webservers act as the "middle tier" which applications talk to. MS is going to wrap its COM components in XML so that way foreign hosts can interpret the data coming in over HTTP requests. As long as the hosts can understand XML, you can write a windows desktop app to interface with it. And this is not just "windows desktop to other platforms". This will also allow non-windows hosts to communicate with windows servers and desktops. They are trying to make it work for two-way communication. I believe it is their whole Biztalk initiative. They even have SQL Server able to return queries in XML format as well as service queries over HTTP requests from a webbrowser by typing the query as part of the URL. Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Joachim Achtzehnter" <joachim@kraut.ca> To: <pgsql-interfaces@postgresql.org> Sent: Monday, November 13, 2000 3:48 PM Subject: Re: [INTERFACES] Connecting remotely - multi tier > Today, in a message to pgsql-interfaces, Adam Lang wrote: > > > > Windows applications in a distributed architecture connect over RPC > > and DCOM. > > If you use CORBA instead of DCOM you can easily communicate between > Windows and Linux/UNIX hosts. > > > or waiting till XML comes around more, > > XML is already everywhere, even Microsoft has XML support. But XML is > just a document format, not a communication protocol, hence even if > you use XML you still need to decide what protocol you use to move XML > from host to host. > > Joachim > > -- > work: joachima@realtimeint.com (http://www.realtimeint.com) > private: joachim@kraut.ca (http://www.kraut.ca)
Hi Adam and all, This is what I meant when I asked about PostgreSQL support of XML. I still wonder the current status and the future plans regarding XML support (since i have not received any reply). Thanks. Philip > their whole Biztalk initiative. They even have SQL Server able to return > queries in XML format as well as service queries over HTTP requests from a > webbrowser by typing the query as part of the URL.
Sorry I didn't reply to you on your first question. I just found out about it for MS SQL last week... and that is only in SQL Server 2000. You can go to the postgresql.org site and look at the todo lists and see if there is any mention of it. If not, there might not be any plans to add that capability. Adam Lang Systems Engineer Rutgers Casualty Insurance Company ----- Original Message ----- From: "Red Pineseed" <yue207@home.com> To: "Adam Lang" <aalang@rutgersinsurance.com> Cc: <pgsql-interfaces@postgresql.org> Sent: Monday, November 13, 2000 4:42 PM Subject: Re: [INTERFACES] Connecting remotely - multi tier > Hi Adam and all, > > This is what I meant when I asked about PostgreSQL support > of XML. I still wonder the current status and the future > plans regarding XML support (since i have not received any > reply). Thanks. > > > Philip > > > > their whole Biztalk initiative. They even have SQL Server able to return > > queries in XML format as well as service queries over HTTP requests from a > > webbrowser by typing the query as part of the URL.