Doug Steele
dbdoug at gmail.com
Mon Apr 26 12:21:25 CDT 2010
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 >