Re: Trigger programme without a trigger.

David Gibbs wrote:

Joe Pluta wrote:
here's a big difference between 'accidental' and 'malicious'.

No there's not. Not when it comes to the end result. If you can't control which users have access to which profiles, then you have ZERO security. Period. I don't care whether it's malicious or accidental, the damage is the same.

If someone has the authority to, and goes to the effort of, removing the trigger (which can't be done unless they can get exclusive access to the file) then their actions are clearly not accidental.

Disagree. Somebody could accidentally remove a trigger just by thinking they're doing it in test. If they're clueless enough to run with the wrong authority, chances are they're clueless enough to run with the wrong library list, no?

That's the problem with trying to prevent stupidity. You can't.

Basing your architecture on the fact that you can't enforce your own security rules seems to me to be a bad way to do things.

However, basing your architecture on the assumption that a single RPG application is going to be the ONLY possible way to update a file when this may not necessarily remain the case, is probably a bad way to do things also.

No it's not. If you design your system correctly so that only certain profiles can access certain things, that's called security. It's sort of the point of the whole process. And if you design your database so that only a single user can update it, then that's called database security, and it's a good thing.

I'm not saying it's the only way, mind you. I'm just saying that it can be done, and it can in fact be done quite easily.

IMO, trigger programs are a fine way to enforce business rules in heterogeneous environments.

It's an approach, certainly. Personally, I give it one and a half stars, because to really put in business rules, you have a lot of overhead, and the overhead can't be removed when needed - for say, a file copy or a mass update.

Unless of course, you have a way to remove the trigger programatically. Of course, the program that removes the trigger could be run "accidentally", thereby leaving you completely unprotected.

Whether or not to use trigger programs, like anything else, is a business decision. Make your decision based on how the design can best benefit your company, not because you can't control your own security. Agh.

If you can'[t count on your security in production, you need someone else in charge of security.

Joe