enter creation password when lookup with qualifiers?

[Bruce Easton]

(inline response)-Bruce Easton, STN, Inc.
Brian K. White wrote Tuesday, January 29, 2008 4:37 PM:
> 
> It's klunky, but we can create behaviour like that now by instead 
> of one lookup line with a variable filename, have a set of 
> literal filename lookups with different filenames, and the 
> variable selects which lookup to execute.
> 
> Not ideal of course but really, is it that horrible for the 
> number of times & places where it must be resorted to
[..]
> I would think this would mostly just impact people who write 
> utils to work on filepro itself, or quasi developer-only tools 
> jhexport which spcifically wants to allow random selection of any 
> file on the system. For those rare situations I'd say it's worth 
> the extra effort of just writing out a process table and then 
> running it. [..]

I've used that technique for specific custom software. 

When writing developer tools, however, your suggestions 
cannot be a choice.  I have several developer 'development' 
and several developer 'runtime' programs using variable 
filename lookups that do not and should not know what filepro 
databases they are going to work with until 1.(in the case 
of development programs) the developer indicates or configures 
the file to be used (configuration taking place external to the 
development runtime program itself - in the same way that cabe 
doesn't know until the developer indicates a file and prc name). 
or 2.(in the case of the runtime programs) the runtime program is 
called.  (In exactly the same way that filepro's clerk doesn't 
know what file it's going to work with until it is called with 
certain arguments.)

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.

Although interesting, the idea of keeping a stored list 
of files to work against and sounds way too inefficient 
for my particular needs.  Burdening some of my programs with 
that type of scheme would be like asking the same of clerk.
[..]
> 
> Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!
> 
> 
> 
> ----- Original Message ----- 
> From: "Bruce Easton" <bruce at stn.com>
> To: "filepro list" <filepro-list at lists.celestial.com>
> Sent: Tuesday, January 29, 2008 3:05 PM
> Subject: RE: enter creation password when lookup with qualifiers?
> 
> 
> > Kenneth Brody wrote Tuesday, January 29, 2008 1:52 PM:
> >> To: gccconsulting at comcast.net
> >> Cc: 'filepro list'
> >> Subject: RE: enter creation password when lookup with qualifiers?
> >> 
> >> 
> >> Quoting GCC Consulting (Tue, 29 Jan 2008 12:34:14 -0500):
> >> 
> >> [... Why does filePro ask for a creation password at runtime on a 
> >>       ...]
> >> {... variable lookup?                                             
> >>       ...]
> >> 
> >> >> > ky = "myself"
> >> >> > fn = "employees"
> >> >> > lookup salary = (fn) k=ky i=a -nxp
> >> >> > salary[10] = salary[10] * "1.5"
> >> >> > write salary
> >> 
> >> [...]
> >> 
> >> > If fp didn't want to break the current code regarding the 
> >> creation password
> >> > and lookups using a variable, there are 2 solutions:
> >> >
> >> > 1. Another environmental variable pfcrpw=no  Turn off asking for the
> >> > creation password at runtime
> >> > 2. Ability to bypass the password at runtime in programming with a
> >> > lookup flag to bypass the creation password request.
> >> >
> >> > This last option does can offer some runtime security by 
> >> allowing using a
> >> > variable but based on the user allow access directly or require 
> >> a password.
> >> 
> >> And these solutions differ from "don't ask for the password", how?
> >> 
> >> -- 
> >> KenBrody at BestWeb dot net        spamtrap: 
> <g8ymh8uf001 at sneakemail.com>
> > 
> > Well I don't see them as being different from "don't ask for 
> the password" 
> > except that they give the developer some flexiblity in controlling the 
> > runtime behavior.  But security-wise, I would think any filepro-savy 
> > user could still do what you showed in your salary example.
> > 
> > What I suggested would differ from the present behavior as follows
> > (based on file XYZ having a creation password):
> > 
> > PRESENT BEHAVIOR
> > ----------------
> > 1.  DEV: Tiny developer BE puts var-named lookup to file XYZ in 
> >    prc table and saves.
> > --- no prompt yet for creation pw for XYZ.
> > 2.  RUNTIME: End-user 10299 is running program at Pal*Mart #845845 
> >    in Walla Walla, WA.
> > --- prompt appears for creation password meant to protect software.
> > 
> > 
> > PROPOSED BEHAVIOR
> > -----------------
> > 1.  DEV: Developer BE puts var-named lookup to file XYZ. 
> >    Prior to saving table, developer hits new hot key in cabe 
> >    that is labeled "Pre-authorize creation passwords."  Cabe 
> > --- asks for one filename at a time or some key to exit. 
> >    Developer BE enters XYZ as the first filename - cabe asks
> >    (as if the lookup was in the table) "enter the creation 
> >    password for XYZ:".  Developer BE enters the password.
> >    If it is OK, then cabe asks for another file.  (If it 
> >    was not the correct password, or if the developer never 
> >    ran this new dialog from the hot key, then cabe would, 
> >    when the table is saved, behave exactly as it does now 
> >    including asking for the creation password at runtime.)  
> >    Developer BE says no more filenames to enter and exits 
> >    the new dialog.  Now, when the table is saved and 
> >    tokenized cabe continues as if the lookup for a literal 
> >    XYZ had been there all along and accessed for use via 
> >    the creation password.  (And in fact, the developer 
> >    had to know the cp to get to get that behavior.)
> > 2.  RUNTIME: End-user 10299 at Pal*Mart runs program.
> > --- there is no prompt for any creation password.
> > 
> > I would think implementing this would mainly involve: 
> > a.  changing cabe to have and use this new dialog for 
> >    pre-authorizing lookups, and
> > b.  changing the runtime progs to not even check for  
> >    (much less prompt for) creation passwords.
> > 
> > 
> > Much more simply, if the behavior were to change in cabe so 
> > that a literally-named lookup (even if not executed) could 
> > pre-approve the creation password, then that would work too, 
> > although it might not be considered a backward-compatible 
> > solution.
> > 
> > Bruce
> > 
> > Bruce Easton
> > STN, Inc.
> > 
> >