John Colby
jcolby at colbyconsulting.com
Tue Nov 11 09:51:48 CST 2003
Gustav,
>I mean - forms don't just open
Of course forms "just open". What do you think the switchboard does? It
"just opens" forms. And plenty of developers use the switchboard.
>and users don't unhide hidden forms
Of course users unhide forms. Users poke and pry, and go where they aren't
supposed to, and find all the chinks in your armor. If it's not supposed to
be done, and you have locked that sucker down tight, a user WILL get in
there!
>he/she would need to either make the button not visible or not enabled or
pop up a message telling that the user has been revoked rights to view the
details; this I guess would be beyond the goal of your LWS tool.
No, in fact that is exactly the goal of my tool. It allows you to create up
to 31 groups and unlimited users. You then add users to groups, ala Windows
or SQL Server. You then tell LWS "These groups can SEE these forms".
"These groups can see this control on this form". etc.
The flip side of this is that any groups NOT allowed to SEE those forms, by
definition CAN'T SEE those forms. And it is the job of LWS to guarantee
that those users CAN'T see forms they are not supposed to see. Thus my
email - how do I GUARANTEE that a form that the user is not supposed to see
remains invisible?
The point here is that every one who has responded so far has simply taken
the point of view that "the developer will guarantee" or "users won't" or
"of course the developer will get rid of menus" etc.
We all know that NONE of these statements are true. Developers
consistently, every day, fail to guarantee... Users, every day,
consistently break into places where they aren't supposed to be, often quite
by accident. And Of course, developers consistently, year after year fail
to remove menus. In fact clients consistently, year after year DEMAND that
menus remain. It is not realistic to start from the perfect world and
assume none of these things happen.
I have a simple question. How many of us know how to build a table. The
first thing all of you will say (waving hand in the air shouting
frantically) is "I do, I do". But in fact I don't have a clue how to build
a table. Or more correctly I can figure it out using DAO, and I can figure
it out using SQL but what do I do under normal circumstances? Use a WIZARD.
The wizard knows how to build a table, I know how to use a wizard to build a
table. Same with queries.
I am attempting to design a system (a wizard) that a developer can use to
set up the type of security we are discussing here, which I call
"presentation security". Light Weight Security allows the developer (or
even the client) to set up the groups and users. Once these two tables are
initialized, there is a "wizard" that allows the developer to select forms
and then assign groups that can Open/See/Edit/Delete/AddRec etc. Whatever
the developer decides is stored in a pair of tables (forms and controls).
Notice that all of these things (except open) are nothing more than
properties of the form. LWS is attempting to manipulate form properties
based upon information stored in tables.
The wizard will allow the developer to select a form, see all of the
controls on the form, and select controls that you wish to lock down such
that only specific groups can See/Enter/Edit.
That is LWS. The group / user login stuff is working. The FORM security is
working (minus a few inconsistencies in being able to hide the forms). The
control security is not finished yet. My post to this group was an attempt
to figure out how to allow LWS to consistently and reliably control the
VISIBILITY of a form. Access does not make it easy, but I have had a couple
of good suggestions that will help me solve this problem.
John W. Colby
www.colbyconsulting.com
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Gustav Brock
Sent: Tuesday, November 11, 2003 4:09 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] A2K - setting a form invisible on open
Hi John
I think Ken has a point here and that you maybe are overcomplicating
the task.
I mean - forms don't just open, and users don't unhide hidden forms;
how should they be able to do that when the developer has designed
menus and toolbars for his/her app?
Also, applying any form of security, light weight or not, the
developer will have to walk through the app from a to z and arrange
for modification of menus, buttons, labels ("Double click her to view
details") etc. If a button is labelled "Show details" on a form and it
should be disabled for certain users, he/she would need to either make
the button not visible or not enabled or pop up a message telling that
the user has been revoked rights to view the details; this I guess
would be beyond the goal of your LWS tool. Leaving the button as it is
and the user presses it and the details form just opens hidden is bad
UI design as the user has no chance for knowing what is going on other
than "it doesn't work".
/gustav
> Ken,
> I am writing a security utility aimed at other developers. It is designed
> to allow YOU (and me as a developer) to manage the presentation security
of
> a database front end. IOW, what forms can a user / group open? View?
Add
> records to? Delete records in? Edit records in? Etc.
> As you can see, I am not necessarily "in control of" the target FE at
design
> time since the FE is YOURS. Why would you want to open a form not
visible?
> Perhaps the form is a filter form that you use to feed values to a query.
> Perhaps the form has a timer ticking that performs some process.
Perhaps...
> uh... I have no damned idea what else you might decide to do with a form
> that is open but that a selected group or groups of users are not allowed
to
> see. I know that I personally use a hidden form to force a cleanup of my
> framework when the database closes. Since a form cannot close without
it's
> OnClose firing, I use that to run a Terminate() function that closes
> everything gracefully. So not matter how the db closes, my term()
function
> runs.
> I cannot allow the users to unhide that since it is a background
processing
> form and they have no business there.
> In the end though, the answer is I don't know why any given developer is
> going to want to open a form that users can't see, I simply know that it
> happens and I need to provide the developer with a means of enforcing this
> security.
---
> 1. It escapes me why you would even want to manage an open, invisible
form.
> If the user can't view it, then by far the simplist thing to do is not
open
> it. Is there some other issue driving this need that you haven't
elaborated
> on?
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com