Creation password at runtime

[Bruce Easton]

George wrote:
> Bruce wrote:
> > I see George Simon's post:
>
> >> Why couldn't a simple:
> >>
> >> video off
> >> pushkey "creationpassword"{"[entr]"
> >> lookup thefile = (fn)  k=1  i=a  -npx
> >>
> >> get around this problem?
>
> > Neat idea - and although this might work (I'd have to test to
> do it only  > once since I have a loop of these lookups), I'm not
> keen on the idea of
> > putting a hard-coded reference of a password in the table -
> that would be, > in my mind, just as much a security hole as not
> asking for the password.
> > Or at least, I guess it would if the file that this prc is in has a
> > different creation password than the one that I'm doing the lookup to.
>
> Do you supply the prc tables to your customers?
> If you don't, then there is no way for them to see it.
>  
> PS- Say hello to Marcia.
>  
> George Simon Sr. Programmer
> Information Technologies
> American River International
>
George, Marcia says howdy.  In this case, it is not anything we've produced,
it's a client support issue.  Also in this case, evidently there is only one
creation password and the end-users at the client site know the password.
prc tables are available, but there is some restriction on access to their
system via the menu system.  So I'm OK in this case, BUT

although I think I understand why it was added to clerk to ask the creation
password at runtime with the advent of var.-named lookups (easy backward
compatiblity, no requirement to store anything more anywhere), I still think
it was a bad idea to bring user interaction with creation password into the
realm of runtime operations and still use the same password and call it a
creation password.  It just doesn't make any sense to me to ever prompt an
end-user for something that in many cases only a developer should know.  The
variable-named lookups have been around for a while and this does not seem
to have been a big issue before - maybe just the likelihood of var-named
lookups against creation-password-protected files is enough of a rarity - we
can only hope.

Bruce Easton
STN, Inc.