Erik:

>> All(?) frameworks include a form manager to manage forms.
>> The form manager usually has a DoForm method which receives
>> some parameters and instantiates a form based on those
>> parameters (whether through DO FORM or CREATEOBJECT is not
>> relevant). The method usually does not verify that the
>> parameters correspond to a form because it is assumed
>> developers will only send valid parameters and, if they will
>> catch any error in development. Note that you could
>> "improve" the method by verifying that the parameters
>> represent a form or a class which baseclass is form. IMO,
>> it's not worth it because the erroneous parameters should
>> be caugth in development.

> Sorry, I'm not following how this pertains to the discussion.

Maybe I should only directed this part to Jim because it was
primarily to show coupling was sometimes desirable, even if it
just assumed. IMO, it also pertains to the security issue
because it shows that identification is not often an issue.

>> What about a situation where an class exists solely to be a
>> bridge (controller) between a UI object (form) and other
>> objects that represent mission critical physical entities
>> (a machine in a production line). The form may only be able
>> to send a limited number of messages to the controller but
>> the controller may be able to send all messages to the
>> machine. I for one, would not want the form to directly
>> send messages to the machine.

> Then obfuscate access to the machine in the controller object.
> IOW, Make the controller object the sole entity with access to
> the machine. This is the same concept as a data access object.

This is what I am trying to do. As far as I know, I can only
do that (in VFP) by creating a subclass of the Control class.
Unfortunately, this won't work in the cases where the machine(s)
are added at runtime. Before you say this makes no sense, I
worked on something like that where we had a listener identifying
when new *things* were added and removed from an environment.
There may be another easy way to do this in VFP but I am not
aware of it. I am looking for something that behaves like a
Friend.

>> Using parameters may not be acceptable because they can be
>> guessed at. I not sure which properties Erik was referring
>> to. If he refers to the machine's properties, does it mean
>> the form must be able to directly manipulate the machine?
>> This would not be any improvement on the on the parameters
>> idea IMO. If he refers to the sender's properties, the
>> machine knows something about the sender. IMO, it's a better
>> idea to authentificate the sender.

> If security is such an issue, why does the form even have access
> to a machine object at all? If the access is there, and you are
> worried about developers gaining unauthorized access to an object,
> what's to keep them from observing the properties of the controller,
> and impersonating them?
>
> I still don't see a valid reason in this case.

I don't want the form to have access to the machine; I want it to
communicate with the controller. The controller's critical properties
and methods of the controler are protected/hidden and thus it is
fairly difficult to impersonate the controller. My problem is that I
don't know how to ensure that a method from the machine cannot be
called from something other than a controller.

Erik, I am sorry if my posts are not crystal clear (I am French Canadian
and did not start using English extensively until 6 years ago). About
half my assignments involve solving some real-time problem and most of
these involve some serious security issues (even death can be a possible
result). I usually work with a team of engineers/programmers/attorneys
and we try to make the systems as fool-proof as possible. I have used
VFP extensively for the past 5.5 years and I have started to like it.
Unfortunately, I don't use it as often as I wish because if an attorney
raises a security issue that may cause the client to be liable and I
don't know how to do it in VFP, I use something else.


Daniel