screens other than 0-9 (was: Re: Windows 2003/IIS6issues...newandimproved ones.)

[Fairlight]

With neither thought nor caution, GCC Consulting blurted:
> Mark, many times you complain about security or lack there of.  Here is an
> instance where fp has added an additional level of security to their
> interface.  Screens can have a password.  So it is possible to have screens
> which are not accessible to the general user base.  Processing can control
> who has access to these non-numbered screens and they could have a password
> to further protect access.

Okay, two points to that.

1) ACLs.  (Access Control Lists) Which would require a real user-based
approach to protecting fP's use in every area.  I'm not going to argue this
point, I'm saying it's a far more elegant and less ham-fisted approach,
period.  It'll never happen in fP, I realise that, and I'm therefore not
going to argue on this point.  I'll just accept that this is how fP does
it, and accept your point about why there are passwords there at face value.
But were it something they'd be willing to rethink, this -would- be a
perfectly valid point, as it would offer the finest control and not have
screen 3 shareable by anyone that knows one shared password.  What happens
when you demote user Z in the company and you no longer want him to have
access to that, but you do want the other 23 people to be able to still use
it?  Now they have to remember the new password.  I include that example
not to argue, but to illustrate why I feel it's a valid argument against
passworded screens as they stand.

2) If there were a devkit onboard the system, what (other than a site
password, which many don't use) prevents someone from just rolling any kind
of screen they want?  And again, in this case, my mind wanders back to an
ACL scenario where you might want to have 2 people allowed to change
one part of the system, a different five people able to define screens,
another 7 doing report design, and 40 people doing different security
levels of use.  But, again, not wanting to argue for what I feel should be,
I'm trying to work with what is...  What prevents someone from using
dscreen if it's there to bypass all the developer's plans on security,
other than a single password?  Assuming none is used (and there are
some valid arguments for not using it from a logistical standpoint), the
whole screen naming convention and rationales are all moot when you can
roll your own.

I note that it is possible to write your own ACL subsystem.  David Jarvis
had one at a filePro class I took in 1993.  But you're still hamstrung (as
far as I can tell, unless someone points to an example) of access to the
ACL control being controlled by a non-ACL solution that's reliant on one
shared password.  Which is rather like putting the combination to a bank
vault on a note locked inside a glass case.  Well, that's a bit of
hyperbole, but I'm really not a fan of shared passwords for a lot of very
good reasons.

mark->
-- 
No matter what your problems, modern medicine can help!
http://members.iglou.com/fairlite/fixital/