|
>ODBC, Client Access and Ops Nav. [allowing access to a file when UPDDTA is secured] >On my old system I got around it simply >not using Client Access, we didn't even have it licensed. Wait 'til some genius opens command-line FTP, does a GET of a file with packed data makes a change to the text of a record and then PUTs it back. Boy is THAT fun to debug. The point is not that there's a problem with Client Access; it's any access other than your code. Some possibilities that exist on every AS/400: File Transfer Support - QY2FTML SQL - STRQMQRY, ODBC/JDBC, embedded in ReXX FTP DDM file AS/400 Java toolkit HTTP server/Net.Data It isn't IBM opening the security hole, it's the changing business environment. The question is: how can we make sure that only authorised people can READ or UPDATE the data? It seems clear that it isn't feasible to close the system to only green-screen access. Given that security isn't painted on at the end of the design phase, we're all going to be revisiting our application design... Ideas to kick around: Securing the files *EXCLUDE and using adopted authority to allow green-screen programs access. This functionally eliminates non green-screen access, which may be too tight. Triggers. Some user profiles might be able to read, but not allowed to update. Some users might be allowed to update but not all fields! More logical files. Use a subset of columns and allow users read/write access to the fields they are authorised to. Exit programs. There are packages that will help here. Custom written I/O modules. Allow only these modules access. Let the green-screen programs call them and publish the interface so other programmers have access. Can double up as triggers if you define the parameter list right. Data warehouse. Have a process (trigger?) copy production data into the "public" data warehouse. If PC users need to change data, the changes go in a transaction file and get a custom process to update production from there. Has anybody here done any of these things? Perhaps that's an answer better kept private... Buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.