Ken Ismert
KIsmert at TexasSystems.com
Wed Nov 12 18:10:40 CST 2003
John,
I agree with Lambert that users are nosy and invasive. However, if you lock
down the interface, and use an mde in runtime mode, you will keep out all
but the most persistent users.
I also have to agree with Gustav that most developers will choose to manage
the user's access by hiding or disabling controls. This means that the LWS
form permission functionality will be rarely needed in production apps.
Is this a drawback of the LWS idea? No... I see several opportunities here:
* LWS form permissions can act as a failsafe if there are leaks in the UI
logic. Because this is an exceptional condition, you wouldn't have to do
anything fancy: just display a message and close the form.
* Developers need a way to query LWS about permissions, something like:
cmdShowSalary.Visible = LWS.HasPermission(CurrentUser, "Open", "frmSalary")
* If LWS could automatically enable/show a control based on a user's
permissions to open a particular form (with no coding on the developer's
part), that would be _way_ cool.
-Ken
-----Original Message-----
From: Heenan, Lambert [mailto:Lambert.Heenan at AIG.com]
Sent: Wednesday, November 12, 2003 10:39 AM
To: 'Access Developers discussion and problem solving'
Cc: 'jcolby at colbyconsulting.com'
Subject: RE: [AccessD] A2K - setting a form invisible on open
John,
I followed your arguments for doing this, and I fully agree with your
comments along the lines of, "if the user *can* do it s/he *will* do it".
FWIW, here's one way you might want to do what you asked for. If you set the
timer interval to 1 millisecond then the form opens without the user seeing
anything but the merest flicker on screen. That's in A97, but it should work
in 2K as well
Here's the form's code module
Option Compare Database
Option Explicit
Const mod_bAllowVisible = False ' simulate user's inability to 'see' this
form.
Private Sub Form_Activate()
' re-hide the form if a user unhides it manually
Me.Visible = mod_bAllowVisible
DoEvents
End Sub
Private Sub Form_Timer()
' Hide the form after it's loaded
Me.Visible = mod_bAllowVisible
DoEvents
' no need to fire this event any more so...
Me.TimerInterval = 0
End Sub
Lambert
> -----Original Message-----
> From: John W. Colby [SMTP:jcolby at colbyconsulting.com]
> Sent: Wednesday, November 12, 2003 9:53 AM
> To: Access Developers discussion and problem solving
> Subject: RE: [AccessD] A2K - setting a form invisible on open
>
> What you're missing is that THIS IS A WIZARD FOR YOU!!!
>
> I have no clue what YOU are doing so I have to desing it as if YOU don't
> have a clue.
>
> John W. Colby
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Charlotte
> Foust
> Sent: Tuesday, November 11, 2003 11:16 AM
> To: Access Developers discussion and problem solving
> Subject: RE: [AccessD] A2K - setting a form invisible on open
>
>
> Am I missing something, John? If you're using a forms class, wouldn't
> there be a test in the Form_Open event of the class to see whether the
> user is allowed to view the form? Or are you talking about users
> managing to find their way into forms already opened hidden?
>
> Charlotte Foust
>
> -----Original Message-----
> From: John Colby [mailto:jcolby at colbyconsulting.com]
> Sent: Tuesday, November 11, 2003 7:52 AM
> To: Access Developers discussion and problem solving
> Subject: RE: [AccessD] A2K - setting a form invisible on open
>
>
> 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
>
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>
>
>
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com