enter creation password when lookup with qualifiers?

Tue Jan 29 13:36:40 PST 2008

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, and the number of possible filenames that would be in each list?
Worst case is if the lookup is a large browse format spanning 2 or 3 lines so that copying the lookup takes a little more care than mindlessly repeating "F8ccc" once for each lookup.

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 have no idea if thats what jh(im|ex)port actually does)

... I was about to say anyone else would have short, or at least fixed, lists of allowable filnames, but I can imagine an application that allows users to create new filenames which are stored in a file, and the allowable filenames could safely be anything found in the filenames file.
You would have to write out processing tables and call/chain/system them in that case.
pretty inconvenient and possiby very inefficient depending on just what kind of loop these dynamic lookups are in th middle of. except, can you dynamically create fileprofiles at runtime anyways?
I guess you can.

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.
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> 
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.516 / Virus Database: 269.19.15/1249 - Release Date: 1/29/2008 9:51 AM
>