RE: triggers within commit cycles -- MIDRANGE-L

Joe,

A trigger does not preclude security checking in an I/O module and can actually
enhance it.  I have used a combination of triggers and I/O modules (in fact they
are the same program) for a few years.  If a trigger is fired without going 
through
the I/O module the I/O module is invoked.  The trigger also know whether it was
invoked via the I/O module.  I have used direct I/O modules in the past and have
found the trigger I/O module combination is far more productive for the 
programmer
and less error prone.

I am a big fan of deriving authority from a combination of program and file. 
That is
prone to error and likely to fail unless you work with a very simple model. 
Having
a single point of access gives you the simplest and most secure model.  The 
biggest
security problem with triggers is that they end adoption.  Before triggers we 
used
adopted authority to support the application/resource authority link.  To get 
around
this we use a controlled profile swap. I am confident that we have sealed the 
cracks
but adoption was obviously the ideal way of handling this.

David Morris

>>> joepluta@PlutaBrothers.com 08/21/01 11:50AM >>>
> From: R. Bruce Hoffman, Jr.

> And a program with a write statement instead of calling that I/O module is
> the same thing as executing DFU. It will circumvent your business rules. I
> know this could start a holy war, that's not my intention.

And a system where you don't know which programs are writing to your
database isn't a particularly secure system.  All I have to do is simply
secure all access to a file except by the I/O module.  What if someone turns
off your trigger?  That's just as likely as someone compiling and executing
a program that writes to a file they're not supposed to.  In fact, turning
off a trigger is more likely, because it's a single command.


> IMO, neither is perfect, but I have a better chance with my business rules
> in triggers than I do with an externalized I/O module. Even if I'm in an
> object oriented language.

A better chance of what?  Of writing a secure system?  Please.  As I said, I
just secure the file to the I/O module and I'm done.  Not only that, I'm
secure from unwarranted access via SQL and DFU.  I can secure access at the
column level, or by field content.

Also, I prefer the flexibility of being able to streamline my I/O when
needed, and changing or even circumventing processing rules as circumstances
warrant.


> As for this particular argument about which is better, I will not
> respond to any further bait.

"This is my opinion, and I don't want to hear yours."  Ah well, you should
know better, I'm going to give my opinion anyway.