Rocky Smolin
rockysmolin at bchacc.com
Mon Apr 26 12:55:26 CDT 2010
I could but 1) there may be more than one BE that a user wants to link to, 2) the client will want to be able to change the password without me having to recode the FE and send an update, 3) users of the app currently can move the BE wherever they want to and relink through the FE utility. So the PW would need to be stored outside the FE. This could be done in a password mdb residing in the same folder with the BE, but then they also have the ability to move the BE where they want it - like they want to do a 'what if' so they copy the BE to their local drive, rename it and link to it to do their 'what if'. No end of trouble here. At the moment, I'm pressing the client for exactly what their security requirements are to see if I can't get him to reduce the requirement or buy off on it completely. As I say, all other clients to this point are in environments where they're not concerned about people going into the back end ad hoc and making changes. Rocky -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Doug Steele Sent: Monday, April 26, 2010 10:21 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Database Needs Password Protection Can't you code the password for the BE into the login/linking logic? Doug On Mon, Apr 26, 2010 at 10:00 AM, Rocky Smolin <rockysmolin at bchacc.com>wrote: > During log in in this app, the user provides their user name and user > password which defines their level of access to the data through the > front end - read only, read/write, administrator. > > As the app supports multiple back ends, there is a utility in the app > to open a different database. At that point, the user would have to > supply the password. > > But if the user has to supply the database password to link the > tables, then they can still open modify back end directly by supplying > that password, yes? Which would defeat this user's primary > requirement that no one be able to access the back end without going > through the front end. I think. > > Rocky > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Max Wanadoo > Sent: Monday, April 26, 2010 9:06 AM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Database Needs Password Protection > > > A simple encryption and password on the BE will provide this. > > When you first link the be to the fe you will need to provide the > password but not for subsequent links if nothing changes. > > Max > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky > Smolin > Sent: Monday, April 26, 2010 4:25 PM > To: 'Access Developers discussion and problem solving' > Subject: Re: [AccessD] Database Needs Password Protection > > The basic problem is that the user need to be able to access the back > end through the front end but not be able to open the back end > directly. Would User Level Security provide that capability? > > R > > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Drew Wutka > Sent: Monday, April 26, 2010 8:07 AM > To: Access Developers discussion and problem solving > Subject: Re: [AccessD] Database Needs Password Protection > > Access User Level security would be faster and easier, though it may > be more of a learning curve for you. In a way, it's a lot like NT > security (but far less secure), so it's second nature to me. > > If you would like some details on how to implement it, let me know. > > Drew > > -----Original Message----- > From: accessd-bounces at databaseadvisors.com > [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Rocky > Smolin > Sent: Sunday, April 25, 2010 2:28 PM > To: 'Access Developers discussion and problem solving' > Subject: [AccessD] Database Needs Password Protection > > Dear List: > > In my manufacturing software users log in with a password that gives > them > 1) > read only, 2) read write, 3) administrator access. But the back end > is wide open. So far this has not been a problem. Everywhere the > system is installed people 'play by the rules'. > > Now comes a client who wants access to the back end restricted. So > I'm trying to think of way to do that with the least disruption to the > system which BTW supports multiple back ends - the user can open a > different back end through an 'Open a Database' utility. > > In the code, of course, I'd have to change all occurrence of > > set db = CurrentDb to > > Set db = DBEngine.OpenDatabase(gstrDB, False, False, ";pwd=" & > gstrPWD) > > > where the password would be in gstrPWD. > > Then I would have to add a utility accessible only by someone with > admin rights, to 1) set, 2) remove, and 3) change the password on the > currently linked back end. Don't know what that code looks like but I > suppose I can figure it out. > > Question is - is this the shortest distance between the two points? > Or is there another approach which would be faster/better/easier? > > > > MTIA > > Rocky Smolin > > Beach Access Software > > 858-259-4334 > > www.e-z-mrp.com <http://www.e-z-mrp.com/> > > www.bchacc.com <http://www.bchacc.com/> > > > > > > > > The information contained in this transmission is intended only for > the person or entity to which it is addressed and may contain II-VI > Proprietary and/or II-VI Business Sensitive material. If you are not > the intended recipient, please contact the sender immediately and > destroy the material in its entirety, whether electronic or hard copy. > You are notified that any review, retransmission, copying, disclosure, > dissemination, or other use of, or taking of any action in reliance > upon this information by persons or entities other than the intended > recipient is prohibited. > > > -- > 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 > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com