enter creation password when lookup with qualifiers?

[Joe Chasan]

On Wed, Jan 30, 2008 at 02:12:29PM -0500, Bruce Easton wrote:
> 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.

if you're talking about storing all this information in an additional
file (aside from prc & tok), then may as well add another thing to that
file - which automatic table is to be associated with the particular
prc table.

--
-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