enter creation password when lookup with qualifiers?

[Joe Chasan]

On Wed, Jan 30, 2008 at 10:50:37AM -0500, Bruce Easton wrote:
> (inline responses)
> Brian K. White wrote Tuesday, January 29, 2008 7:09 PM:
> >  
> > > So because of this limitation, currently I have no way to 
> > > password protect my utility programs for distribution 
> > > without an end-user being prompted for a creation password.
> > 
> > Did you get what I meant by writing out a process table?
> >
> 
> Yes - interesting idea, but to me not practical and I think 
> there may be more of a hurdle here.
> 
> > Table A originally wants to lookup a variable file and do some work.
> > Can the work possibly be collected into a call table and run there?
> > 
> > If so:
> > * modify table A so that all the dynamic lookup work is done in 
> > one or more call tables.
> > * write a new table B which has a lookup using any file you want 
> > or a variable, just so it passes syntax check.
> > * at runtime table A determines it wants file foo.
> > * use a little readline/writeline or import/export loop to read 
> > table B and generate a new unique temporary table C. This loop 
> > can be a nice black box call table itself.
> > It's small enough to be fine even as a gosub.
> > * table C contains a litteral lookup to foo in place of whatever 
> > table B had
> > * call C
> >
> 
> Regarding practicality and efficiency this would not 
> cut it for, say, being utilized in the middle of a 
> record update live transaction.
>   
> > 
> > Result:
> > o table B can be developed/maintained in cabe naturally
> >   (no stack of zz="label:if...:then...:" in table A)
> > o foo can be unknown before runtime
> > o foo can have a creation password
> > o user will not get prompted for creation password
> > 
> > Since this is possible, I would say it makes the fp built in 
> > feature moot and so might as well be removed. It's not actually 
> > protecting anything. Is it? Am I missing something?
> 
> Well, I think it would take more experience than what is 
> needed to write what Ken wrote in his salary example.
> 
> > 
> > Ouch, snag... at run-time the user must either be running dclerk 
> > to call the temp table, or have rcabe available to tokenize the 
> > temp table before calling it.
> >
> 
> Yes - and when trying to use rcabe to tokenize the called table, 
> one should get prompted then for the creation passwords.

As Brian pointed out, since tables can be created at runtime, throw
the security aspect of it out the window.

The runtime prompt for creation password has been a pain for me.

Way back when I first complained about it, someone @ fp-tech suggested
that I hardwire any and all lookup combinations that the variable lookup
might resolve as elsewhere on the table (and it does not have to be
in an excecuted portion of the table).  I thought this was a good way
to solve it (as *cabe could prompt you at time of create the prc table
and *clerk would have some sort of internal table that remembers that
file X / Qualifier Y was already verified and not bother me with it)
- unfortunately this approach did not work and I still got prompted
at runtime.   I beleive if *clerk/*report is fixed to work in this
way all can be solved with no backward-compatibility issues at all
(which i can't say for some of the other suggestions)

--
-Joe Chasan-                           Magnatech Business Systems, Inc.
joe - at - magnatechonline -dot- com   Hicksville, NY - USA
http://www.MagnatechOnline.com         Tel.(516) 931-4444/Fax.(516) 931-1264