|
This is a multipart message in MIME format. -- [ Picked text/plain from multipart/alternative ] I believe that this can all be done. I seem to remember some difficulties with this though. Issues you are trying to do: 1 - Modify the buffer on the read event prior to it being passed to the requester. 2 - Perform row level security. I question as to whether or not you'd be better served by securing the physical file so that no one may directly access that and then ensure that all access is done via the logical(s). This has been around since day one of OS/400. The newer stuff may be how you create this logical file. Let's say your row level security is too complex to do with simple select's and omits in DDS. Now you can use more complex calls via SQL. For example, if you only want them to see information on employees with a security level that is less than or equal to their own this can be whipped up quite easily in the CREATE VIEW. Now let's pretend that you want to control what appears in the columns based on this same situation. Your view may be based on the following: Select empno, wage(empwage, empsec) from empdata And wage() may be a UDF that analyzes the current job user and determines if that person has any right to see that information. If so, pass back the wage, if not then pass back zero. A trigger can easily modify the input buffer, much like the suggested UDF. The problem with using a trigger is that the trigger has a tough time with row security. Correct me if I am wrong but I think it can only fail the trigger program, by passing an exception message. It can't just say 'skip reading this row'. And if you are thinking narrowly then you might think 'no problem'. I can modify the program I am concerned about to monitor for this exception. But what about every query, and other program which reads this file? Getting the CPF9898 with a 'You aint freaking authorized' exception message can be user vicious. Granted, instead of the exception method you could modify every field in the input buffer to blank it out but that is no security. Let me give you an example. If I was to run a query against this file and selected my coworkers employee number and a salary greater than mine what should happen? Should they get the standard query 'No records selected'? Yes. Should they get a bunch of blanked out fields? No. That could be used to determine the employees salary. Should they get an exception CPF9898 with a 'You aint freaking authorized' message? No. For the same reason given above. If someone can figure out how to get the trigger to return successfully with no buffer, so that it meets all this criteria I would be happy to know how. This is why I suggest the View method. Rob Berendt -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Raul A Jager <raul@abc.com.py> Sent by: rpg400-l-admin@midrange.com 10/03/2002 02:49 PM Please respond to rpg400-l To: rpg400-l@midrange.com cc: Fax to: Subject: Read Trigger I understand that this topic is more related to the DB2 than the RPG program that uses it. I wander if a RPG trigger at *READ event can chage the buffer so the program receives a modified data. Also if the trigger can forbid an user from reading certain records, and allow others to read it. I'm sure that is in some manual, but all I cloud find is INSERT, UPDATE and DELETE. TIA. Raul _______________________________________________ This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list To post a message email: RPG400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l or email: RPG400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/rpg400-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.