enter creation password when lookup with qualifiers?

[Bruce Easton]

joe at magnatechonline.com wrote January 30, 2008 12:03 PM
> 
> 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)
-------
It would be a simple fix, but it would definitely not backward-
compatible.  Let's say Millard the Masochist programmer coded 
in a table one hard-coded lookup to XYZ for one purpose and one 
variable lookup to XYZ where his client actually wants their 
personnel to have to answer the password prompt at runtime.  The 
way clerk behaves today, personnel would be prompted for the 
creation password at runtime when that table looks up to XYZ.
Make the change you're talking about and boom - security out 
the window for Millard and his client. I would never code 
something that way knowing how poorly this feature is 
implemented and what bases it was designed to cover, but when 
it comes to backward-compatibility, any possiblity of non-
backward-compatibility should be enough to prevent a new 
change in behavior.

My suggestion of allowing the developer to, in cabe, pre-authorize 
lookups to one or more files (even though literal lookups are not 
there)(and be required to enter creation passwords as 
necessary during that dialog), I believe would be backward-
compatible and should work well with the way in which filepro wants 
to authorize a developer  for access to lookups to files prior to 
being able to successfully save a processing table.  This would 
be backward-compatible because if the new dialog and functionality 
were not used (which would include existing prc tables), the 
program would work just as it does now.  This would 
also, I believe, allow the current mechanism (that really should 
be divided) to continue where both data access and software 
protection issues are being addressed simultaneously.

Bruce

Bruce Easton
STN, Inc.