[AccessD] Lightweight security

>Good to hear you're putting together something that is plug-and-play.

Not exactly plug and play as of yet.  There are a handful of tables and
forms required, as well as a library.  Once all that stuff is in place it
will still require the developer understanding and using code to enable /
disable forms opening / edit / delete etc, and if desired at that level, the
same for controls on forms.  Or at the least understanding that LWS is
manipulating specific properties of forms and controls so that they
understand why a form's records can't be edited or can't be deleted etc. for
some users but not for others.

It really does work though.  I have code working that will allow / disallow
opening the database itself (modal login form), opening specific forms based
on user / group membership (LWSForm class), viewing controls on specific
forms based on user / group membership )LWSControl Class) etc.

In actual fact while it does require a class for each object modeled (user /
group / form / control) each class "knows" how to set itself up, apply it's
security  to it's object etc.  Doing it as a set of classes using tables to
hold the security info made it waaaay more straightforward than my old
method.

The nice thing is that once the "physicalness" of it is set up, i.e. the
user / group records created, the form's properties assigned to groups,
control's properties assigned to groups etc. it can be blended into a
framework such as mine with a minimum of effort.  A call as my framework
initializes loads the LWS system.  My form class has code that instantiates
a LWSForm class (if a SysVar says we are using LWS).  That class
instantiates all the LWScontrol classes, and voila, security down to the
control level - virtually with a single call in my framework's form class.

Since the LWSForm class is passed a pointer to the physical form, it can
directly manipulate the properties that it controls (edit/delete/addrec etc)
so that the form security is virtually automatic.  The only issue here is if
you use a toolbar (as I do) to toggle edit mode, it will have to check with
the LWSForm class to determine whether it can allow editing.

Likewise each control class gets a pointer to the control it is applying
security to, so it can also directly apply security to its control -
visible, locked, enabled.  This really is a no brainer, it just happens
according to the info in the LWS Control table.  If you belong to the right
group, you can see / edit / enter the control, else you can't.

At the FE / physical level, security is then manipulated using a wizard to
view / change the form / control security information in the tables.  BTW,
the wizard is NOT functioning yet in the new LWS.  I had that working in the
old LWS but the physical layer is entirely different and I will have to
build a new wizard for this version.  I have manually tested this stuff
though using crude debug window ORs to set the group info for forms and some
controls and it is working.

And the nice part is that if you embed this in a framework, even the most
determined power user is going to have a hard time disabling this stuff
without completely breaking the application.  Having it launched down at
this level makes it virtually impossible to get around.

For those without a framework it is still as simple as the following code in
a form:

Option Compare Database
Option Explicit
private fclsLWSForm As clsLWSForm

Private Sub Form_Open(Cancel As Integer)
    Set fclsLWSForm = New clsLWSForm
    fclsLWSForm.Init Nothing, Me
    Cancel = Not
fclsLWSForm.FrmOpenEnabled(gclsLWS.UserCls.UserGrpMembership)
    If Cancel Then
        If gclsLWS.cSysVars.SysVar("gLWSInformUser") Then
            MsgBox gclsLWS.cSysVars.SysVar("gLWSInformUserMsg") & " : " &
Me.Name, vbInformation + vbOKOnly, "LWS SECURITY AUTHORIZATION DENIED"
        End If
        Exit Sub
    End If
End Sub

The problem with just doing it here is that the How and Why (and that it is
happening) is visible right in the form, making it trivial for even basic
programmers to disable.  Put the same thing out in a framework MDA and the
cost to find and disable it goes up enormously.  Compile the framework and
it is locked down.

As you can see though, in the end it will still require programming skills
to use.

John W. Colby
www.colbyconsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Christopher
Hawkins
Sent: Monday, October 20, 2003 2:01 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Lightweight security


This sounds nice - I have built similar setups for multiple clients
in the past, starting fresh each time and never taking the time to
genericize it.  What a knucklehead.

Good to hear you're putting together something that is plug-and-play.

-Christopher-