Creation password at runtime

[Bruce Easton]

I wrote moments ago . . .
>
> > 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.
>

I guess if you view creating a lookup or browse lookup into a file as
creating or modifying a VIRTUAL or ALIEN format of that other file, then I
can see why you can argue needing to prompt for the creation password - but
your original definition of creation password is really stretched in my
mind - especially as I mentioned since creation password by itself does not
protect viewing/updating of data directly.  But if you are insistent that
lookup creation maintenance be included as formats to a file even though
they are not in the file, then fine.  But then, what was needed with the
advent of variable-named lookups was something else like what I proposed
above (first suggestion) to match the new var.-named lookup feature (let's
call the matching technique I suggested "variable pre-prompting of creation
passwords in cabe"), rather than prompting an end-user in clerk.  I cannot
see where prompting for the creation password in clerk would ever be a good
idea as long as you are calling and have defined it as a creation password.

Bruce Easton
STN, Inc.