Re: Read Trigger

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.