Re: User Spaces

[Barbara Morris <bmorris@xxxxxxxxxx>]

Joel Cochran wrote:
> ...
> For a new application we are writing there will be a security
> configuration file.  Each user will have authorities set at the option
> and function key level.  Naturally this is all DB driven, but in essence
> each authority gets verified at three differenct levels.  At screen
> display time to determine whether or not to display an option; at option
> processing time to verify that the user did not select an unauthorized
> option, and at processing time to make sure that no back doors were
> taken in getting there.
> 
> Given that this processing will need to take place for every screen,
> selection, and processing, it appears to me that this may be overly
> burdensome on the DB.  So to bring this back to User Spaces, I'm
> wondering if it would be better for us to read the authorities in once
> when the user signs into the application, store them in a User Space
> unique to that log in, and then access the user space for the
> verification instead of the DB.  I'd probably create the User Space in
> QTEMP so that the GC is taken care of automatically.
> 
> Would this be faster, better, etc, or am I making a mountain out of a
> mole hill?
> 

It might be faster, but if you have to read in all the authorities into
the user space, and then possibly only refer to a couple of them, you'd
have done unnecessary DB access loading the user space.  Whether it
would be better would depend on how nice you made the interface to the
user space - a based data structure would work, but it would be
difficult to maintain if you added new authorities or screens or
whatever.  I also vaguely wonder if the user space would be as secure as
the file.

An alternative, that may or may not be faster, is to create a service
program in a named activation group (or *CALLER if your entire
application is in the same actgrp) which will do all the authority-file
access.  Each procedure in the service program would give out a
different piece of authority information from the file.  The procedures
could cache the information in a static variable, and only have to fetch
it the first time.  I don't know if this is better either, but I think
it would be easier to use in the application.

Something like this, guessing wildly at exactly how your authority thing
will work:

H nomain
Fautfile   if e    k   disk

 /copy autprocs

P autToApp    b               export
D autToApp    pi          n

D ok          ds              static inz(*off)
   
    chain to file and set ok to whether
           the user is authorized to the application
    return ok

P             e

P autToScreen b               export
D autToScreen pi          n
D  scrname              10a   const

D             ds              static
D  cache                      dim(1000)
D    scr                      like(scrname) overlay(cache:*next)
D    ok                   n   overlay(cache:*next)
D i           s         10i 0
D numscreens  s         10i 0 inz(0)
   
         i = %lookup(scrname : scr : 1 : numscreens)
         if i <> 0
             return ok(i)
         else
             numscreens += 1     
             scr(numscreens) = scrname
             chain to file and set ok(numscreens) to whether
               the user is authorized to the screen
             return ok(numscreens)
         endif

P             e