>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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.