John Colby
jcolby at colbyconsulting.com
Mon Oct 20 11:16:15 CDT 2003
Thanks. I guess that means A2K and up only. John W. Colby www.colbyconsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Charlotte Foust Sent: Monday, October 20, 2003 11:58 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Lightweight security CurrentProject was introduced in Access 2000. It will break in Access 97. Charlotte Foust -----Original Message----- From: John Colby [mailto:jcolby at colbyconsulting.com] Sent: Saturday, October 18, 2003 8:58 AM To: Access Developers discussion and problem solving Subject: RE: [AccessD] Lightweight security BTW, I meant to state that this is being developed in A2K. I am using ADO connections and CurrentProject.Connection and CodeProject.Connection syntax, which I'm not sure works in A97. If they do then this should work fine in A97. John W. Colby www.colbyconsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John Colby Sent: Saturday, October 18, 2003 11:27 AM To: AccessD Subject: [AccessD] Lightweight security Folks, I am working on my Light Weight Security system and am looking for beta testers, i.e. people who would like an interface level security system such as I am designing. This email will briefly outline how things work so that you can decide whether you would like to test it. I am looking for PROGRAMMERS as beta testers. LWS is currently a "monitor" only system, i.e. it doesn't directly affect the form or control, it only allows the developer to ask questions like "should this user (belonging to this set of groups) be allowed to open the form, see this control" etc. Thus the developer needs to be capable of writing code to query the classes and apply the answer as (s)he sees fit. I may, at a later date, add the ability to have LWS actually set the properties discussed below which would allow use with less programming but for now that isn't in place. LWS is designed to restrict basic operations on forms and controls. The form operations / properties that it will affect are Open form, Edit record, Delete record and Add record. The control properties affected are Enabled, Locked, and Visible. LWS is NOT designed to replace Access' (or SQL Server's) security. LWS is designed to allow the developer to restrict operations at the INTERFACE level, i.e. who can open forms, who can edit records in a given form, who can SEE a given control on a given form, who can EDIT data in a given control on a given form. These are fundamentally different issues than the built in DATA security that Access and SQL Server provide. I designed LWS because my clients asked for things like "only allow certain users to be able to see (or use) this control" or "only allow certain users to be able to open this form" etc. As an example I occasionally have controls that reassign child records to parent records (change the parent). This is a "Supervisor only" operation and requires either going directly into tables, or building specific forms if I don't have a system like LWS. with LWS I can set the control Invisible as the form opens unless the user belongs to the Supervisor (or Administrator) group. LWS is designed around a Users / Groups metaphor similar to Windows NT/2K/XP etc. Users exist but don't directly have any innate abilities. Users belong to Groups. Groups can do things. There are a set of tables that support the LWS system: uSysLWSUsers contains user information - Name, PEID (mapped to your Personnel ID if you desire) and password hash (MD5). usystblLWSGroup contains group information - Name and the 2^x bit that is used for mapping it's abilities later. usystblLWSGroupUser contains mappings of users to groups. A simple m-m uSysLWSUsers and usystblLWSGroup. MsysForms contains form security information - Form ID, Form name, Open, Edit, Add and Delete maps. MsysControls contains control security information - Form ID, Control name, Enabled, Locked and Visible maps There are a handful of forms to support LWS: usysfrmLWSLogin - The login form. usysfrmLWSUsers - The form for setting up users. usysfrmLWSGroups - The form for setting up groups. usyssfrmLWSGroupUser - The form for mapping groups to users. usyssfrmLWSUserGroup - The form for mapping users to groups. usysfrmLWSSetupFrmSecurity - The form that assists the developer in setting up form security LWS is NOT finished, but all of the basic tables are in place, I am using the login in my apps, and the code to monitor forms is up and functioning. The code to monitor controls follows the same form and will be available within the next week or two. LWS will be a library (MDA for now) with full source code available to beta testers. Please remember, I am looking for "code jocks" for now. You should be comfortable instantiating classes, calling class methods and setting class properties, manipulating form and control attributes via VB etc. I will ask for a NDA since ya never know... Beta testers will be given a single developer license to use the finished product, which is more than MS gives you! I think this should give enough information to allow you to decide whether you are interested. If you are interested, please contact me OFF LIST at LWS at colbyconsulting.com. John W. Colby www.colbyconsulting.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