Architecture

2005-02-08

Today interesting quip was spewed forth during a security system
architecture meeting. Don’t get me wrong here. I’m all for security in
software, and I’ve written a couple of security modules for financial
apps. Because of this, I once again made the mistake of approaching the
conversation with some knowledge, ideas and intellect.

We were discussing when the security system should check the database
for the user’s security level for, say, a given form and it’s child
controls. It went something like this:

FD (Fellow
Developer): If we’re allowing the client company to
configure individual permission levels while the system is running we
will need to check the security as late as possible.

Me: Sure, if the
end users want to see the changes reflected as promptly as possible. We
can just check the database when we open the forms.

FD: What if a user
has that window open and a new security setting is given to them which
restricts the windows functionality? How are we going to handle that?

Me: Is there a way
we can handle that? Maybe we can use a timer and reload the security
and reset the form when it fires? That’d be some ugly code.

FD: Yah, that’d
suck. There’s gotta be a way to make the client software smart enough
to react to any change made in the database.

Me: Don’t know, don’t know.

So if anyone has a spectactular way of make a client application fire
an event when a different instance, most likely on a different piece of
hardware, edits or adds to a database, I’m all ears. Until I get
enlightened, I’m just going to shrug, smile and plead ignorance.

uncategorized