Creation password at runtime

[Bruce Easton]

Any thoughts to my ealier suggestion of an enhancement to fp? (edited for
emphasis)

. . .
> where a combo key of processing table name + creation password (CP) could
be
> stored in a new special key - say "cp_ok_key" and that could ALLOW THE
> DEVELOPER TO PRE-AUTHORIZE LOOKUPS into creation-password-protected files.
>
> i.e., you're in rcabe and

> UPON SAVING THE TABLE, a NEW OPTION when selected would allow you
> to enter one or more filenames, and for any filenames that
> are password protected,

> the password would be prompted, and if it is
> validated, an entry is made into the "cp_ok_key" special file (usable only
> by *cabe,*clerk,*report). Then at runtime, before asking for a CP for a
> variable-name file, before asking for a CP, this special file is checked
for
> the table name-filename combo. If it's there, then no need to ask CP
again.
> I don't think backward-compatilbility would be a problem with this, but
then
> again, I haven't thought much about the level of automatic maintenance
> something like this should need from the cabe and clerk programs.
>
. . .

My only problem now that I look at this again, is

1. filepro's auto-maintenance of this file - what would that be like?? and

2. it seems like it could be spoofed - i.e., someone seeing somehow a table
that gets thru to seeing/updating a file that they want access to (that they
are not supposed to have) and then temporarily moving the table out of the
way and slipping their own table in place.

But, regarding #2 above, maybe this special new file could hold:

1. filepro file name that has the creation password
2. table name (that is currently being saved
3. sum / byte count - something that can be compared to the current table
running

So "cp_ok_key" would become a standard part of your filepro files, just like
key, data, lockfile, etc.  If it's not there, the program works as it does
now (backward compatibility).  If an entry in "cp_ok_key" does not match
exactly as it should with what is being used at runtime (the current table
where a var. lookup is in question), then the program works exactly as it
does now.  But if the entry matches exactly, then a creation password is not
asked at runtime.

So you might have entries (encrypted though for use only by fp) in this new
type of fp file for my original example like:

APP,mytablename,4355
OTHERFILE,mytablename,6234
YETANOTHERFL,table4,3244

where APP is the filepro name with the creation password
where mytablename is the table name
where 4355 is a sum or byte count when the table was last saved

So in the above example, mytablename is pre-authorized to do lookups into
APP and OTHERFILE with respective sizes 4355 and 6234 without asking for a
CP at runtime.

Wish I could come up with something simpler for something that doesn't seem
to come up much - but I'm trying to think about building on what is in place
now. With the addition of an optional new type of filepro file, this
obviously would require mods to cabe (to ask the new additional question and
store data in the new file) and clerk (to check the new file if there and
act accordingly).

Bruce Easton
STN, Inc.