limiting browse based on login?

[Bruce Easton]

Mark wrote Wednesday, September 02, 2009 12:59 PM
> 
> On Wed, Sep 02, 2009 at 12:34:43PM -0400, after drawing runes 
> in goat's blood, Bruce Easton cast forth these immortal, 
> mystical words:
> > 
> > Mark - how is a qualified file not 'protected' verses an 
> unqualified file?
> 
> All someone needs to do is:
> 
> [be somewhere they can drop to a shell]
> [drop to shell]
> PFQUAL=qualifier;export PFQUAL
> [run clerk or report]
> 
> You can skip the environment variable if you remember the 
> flag for clerk/report.  I -think- it's -M but would have to 
> look it up.
> 
> It's not like qualified files are encrypted.  They're named 
> differently.
> This isn't rocket science.
> 
> mark->
> --

Well if you can drop to a shell, you can drop to a shell and any 
solution - using qualified files or not is a potential problem.  

I like Tom Aldridge's solution as a complement to what I and others 
were suggesting because of the simplicity:

-It doesn't involve using additional indexes for your internal 
primary file.

-It keeps the separate clients usage of the files really separate.

-It doesn't require much magic code for the user interface part to 
work and allows one to enter and use standard clerk features in a 
standard way.

The only drawback I can see for this as a character-based solution is 
the up-front time the user must wait before they can access their 
up-to-date data.  (And I'm guessing this has not been a problem for him.)

I haven't used this technique, but it seems like something that was 
probably a good solution before BBOCD (when @menu and @entsel came into
being:  
the Big Bang of Overly-Complicated Design).

Bruce

Bruce Easton
STN, Inc.