Re: ODBC and Security

Sorry for quoting a long article...I'll cut as much as possible ;-) In article <3138AC04.2DED@centrum.is>, "John H. Frantz" <frantz@centrum.is> writes: |> Mike Sullivan was concerned about security issues when using |> ODBC connections to his database (his article is included at |> the bottom). |> |> In short: Most complex databases have rules and restrictions |> about data entry and maintenance that are programmed into a |> central application. But, if users have SQL access to modify |> data, they can do so using any client program, including ODBC |> client software, opening up the possibility of data corruption. |> |> There are two solutions that I have considered. First, you can |> program all the rules and restrictions within the database |> using constraints, triggers and stored procedures. This is |> great in theory because now any client program will conform to |> the rules when modifying data. However, this method can be very |> complicated and difficult to implement. Although I haven't |> followed this route and I can't say what animals you might run |> into, I have found that the stored procedure language is not |> very robust. I'd agree with this accessment. SPL really wasn't built with this type of stuff in mind (I think). |> <SNIP> |> |> I'm actually surprised that more people aren't concerned about |> this security issue. Maybe they don't realize the danger or |> they trust that the users won't be "clever" enough to find the |> loopholes. I think they're just blindly following the trends, |> but who is leading? There are some people who are; me for one. I've got users breathing down my neck to use Microsoft Access (and others) on our corporate database. Currently the security for the database (which is 3rd party) is provided via application (discussed in the above <SNIP>) and of course this fails when another 3rd party tools in pointed at the database. |> |> One question is whether you really need a graphical user |> interface for the maintenance of your data. I have found that |> the true need for graphics is in reporting tasks to effectively |> present information, which requires only read access. On the |> other hand, programs that maintain critical data (the kind that |> you deem transaction loggin necessary for) are best served by a |> centrally controlled, stable and secure system. In my opinion, |> todays two tiered client-server tools don't fit that bill. |> Maybe New Era's upcoming three tier architecture will do it, |> but on the other hand maybe the future of client-server will be |> with www browser tools like Java from Sun. Meanwhile |> Informix-4gl does the job. This is a route that I am very interested in and persuing. It has many advantages: cross-platform interface (even character is supported ;-), relative ease of security (can use the security built in the to browser/server), and the tools are here today. |> |> Anyway, how is everyone else handling the security issue with |> ODBC. I would be very interested in any comments. |> |> Sorry about the long article. |> +---------------------------------------------------------+ |> | John H. Frantz | |> | Power-4gl: Extending the Informix-4gl user interface | |> | http://www.strengur.is/~frantz/pow4gl.html | |> +---------------------------------------------------------+ |> |> Mike Sullivan wrote: |> > <Mike's original post SNIPPED to save space here...> Mike -- ---------------------------------------------------------------------------- Mike Reetz reetz@ucar.edu 3450 Mitchell Ln BIS Computing System and Network Manager (303)497-8881 FL1 UCAR - University Corporation For Atmospheric Research Boulder, CO 80301