Creation password at runtime

[Bruce Easton]

> Ken Brody wrote (Sunday, January 21, 2007 1:49 PM)
>
>> Quoting John Esak (Sun, 21 Jan 2007 11:01:59 -0500):
>>
>> For that matter... the *whole* key file could be searched in the same
way,
>> so if it is Payroll data we are trying to keep password protected for
>> instance... what does it matter if the password is viewable
>> in the tok file when the actual data is visible in the key?
>> I think if you have users doing this kind of thing in the first place,
>> you have more trouble than hiding a password.
>
> Well, 5.6 does have data enctryption available if you need it.
>
As I said before, I understand why you want a way to protect data, such as
payroll, but I still do not agree with the useage of creation passwords (nor
the design in fp to allow the usage) to achieve this.  And before this
occurrence for me involving a variable-named lookup, it really has not been
an issue, because, the more I look at it now, in my mind, the misusage of
the creation password in trying to protect viewing of data was not in the
face of the end-user.  It, until now, was only a hinderance when the program
would ask you for all those creation passwords for other files you are
looking up into (as the developer).  Now with variable-named lookups,
evidently it IS in the face of the end-user.

Now, looking back, I realize that this was a flawed design even before the
advent of variable-named lookups.  Again, I go back to the page of the 3.0
manual which clearly states that the purpose of the creation password is to
protect the developer's formats and file structure. And it even states that
is does not prevent viewing/modification of data.  The way I see it now - a
creation password should never be prompted for lookups into file that has
one.  Correct me if I am wrong, but how does being able to do a lookup into
a file that has one without having to enter it when creating/modifying
processing in another file jeopardize the formats of the file that has the
creation password? (brw/map/screen/out/sel/brwlook/prc/tok/qualify/index[as
far as what fields is the index build on])

Moreover, if I don't put a screen password, menu password, some other method
to protect sensitive data on formats for a file that HAS a creation
password, then the end-user can go directly into the file and view/update
the data (just as advertised).  So why mess up the purpose of the creation
password as stated with trying to protect data via lookup?  Makes NO sense
to me now.  The net result is now we have a password prompt coming up at
runtime that a developer probably would never intend, AND therefore the
developer might be reluctant in using creation passwords for their originial
stated purpose.

I've suggested one possible solution involving a new type of filepro file
(like key/data/map) to that could be written to only by filepro that would
allow the developer in cabe to add to the list of files that filepro thinks
need prompting for creation password, so that clerk can check this file and
know that it has been pre-approved (even though the file does not have a
hard-coded ref in the table - see my ealier post - I think this would be
pretty backward-compatible).

Maybe another solution would be to have an environment var that, if set,
would cause creation passwords to never be checked for lookups into file
that have them.  (This would mean that you would only get a creation
password prompt for the file of the processing that you are getting ready to
modify - no prompting as you save the table - this is how it should have
been from the start.)  This suggestion would be too easy to get around by
itself, so there would have to be some other controlling mechanism in place
(similar to site password) to allow clerk to consider the new env. var.
(i.e., after installing filepro, set a "CPENV" site-type password - then at
any time the developer or controlling person could after entering that
password, turn ON or OFF whether or not the new env. var. "PFNOLOOKUPCP" is
considered by clerk.  Something like this would eliminate all those
prompting for CPs during saving of processing.  Maybe this could be
backward-compatible if the default is to have things work as they do now
(again, anything required to make it work the new way must be present and
set or behave as it does now).


Bruce Easton
STN, Inc.