How to secure a Finished Program

btp111

Registered User.
Local time
Today, 03:01
Joined
May 8, 2008
Messages
15
Hi,

I have a new program and this is the first one I have made in MS Access 2007. I have split the DB so I only have links on the Front End to the BAck End Database. I want my users to only see the forms and never see the DB Links. I have tried going to
Office Button --> Access Options --> Current Database --> Uncheck Display Navigation Pane
That works but the user could go right back in and check this and have the ability to link to my DBs. If that occurs they could make major changes to the DB that would cause problems.

Is there a way to make an Executable out of this program so they only see the forms that I want them to see? Any advice on this is really appreciated.

Thanks again.
 
No, no executables for Access.. You can make a MDE tho, which is much closer to an exe in the sence that it cannot be changed.
Not 100% ... but ... OK.

Good luck
 
Namliam,
Thank You. I tried to make the ACCDE file and it errored out with the following error:
This error is usually associated with compiling a large database into an MDE file. Because of the method used to compile the database, a considerable number of TableID references are created for each table. The Access database engine can only create a maximum of 2048 open TableIDs at one time. Exporting a database as an MDE potentially can exceed this limit if the database has a large number of objects (table, macro, form, report, etc).

However, this is a small DB with only 5 tables and 4 forms so I know it isn't because of the size. Any ideas on how I can get around this?

 
Nope sorry, I have only made MDEs at requests of my customers once or twice.
All times worked like a charm, I do know that MDE are much more prown to error than Access dbs.

i.e.
In access you can have a form with a module behind it without any code in it.
In a MDE that will cause an error for some reason.

Creating a MDE in general is a headache I try to avoid ....
 
Creating an .mde or .accde will not solve your particular problem since the Navigation Pane is still accessable. you can set the attributes of the linked tables and queries to hidden so they don't show up and that will defeat the casual user.

Try compacting your database and compiling it to see if that clears up the error you are getting.

Don't forget to keep your .mdb or .accdb in a SAFE place. There is no going back to it from the .mde or .accde.
 
Creating a Secure Program in Access

Hi Pat,
I am also worried about the user who may go to the Access Options and recheck the Navigation Pane. Does anyone know of a program you can buy that may be able to make a group of Forms in an Access file to absolutely stop this from occurring or any other way to do this?
Thank you,



Creating an .mde or .accde will not solve your particular problem since the Navigation Pane is still accessable. you can set the attributes of the linked tables and queries to hidden so they don't show up and that will defeat the casual user.

Try compacting your database and compiling it to see if that clears up the error you are getting.

Don't forget to keep your .mdb or .accdb in a SAFE place. There is no going back to it from the .mde or .accde.
 
There is no such thing (as far as i know)

However you can "disable the shift key" that one can use to bypass the startup commands.

In the startup commands you can disable the default menus and add your own, that way no one is able to get at your options to change anything. Thus ensuring that everything that is hidden stays hidden.

Have a search for "disable shift key" or something like that and you should find the code needed to implement this.

Good luck!
 
Question on Startup Options

Hi Namliam,

I have one question. I believe I can disable the shift key but couldn't all users go to the Office button --> go to Access Options and change the default Options I set up on this DB? Is there any way to disable this so that the user cannot get to these options.

Do you know if User Level Security is available in Access 2007?
Thank you.
 
User level is available in any version...

Stuff like shift key disabling is dependand upon any database, so any changes made to "global" option by general users is not important.

If you are looking to "distribute" an Access DB to people who would otherwize not use Access, maybe a runtime version with extreemly limited functionality would be something for you?
 
Run Time Version with Limited Capability

Hi,
Yes a runtime version would be great. I did not know this was an option. Do you know where I can find information on how to create a run time version with limited functionality?
Thanks again.
 
You dont create a runtime, the runtime I am refering to is the Access Run-time.

A bare shell that runs your Access db. Offcourse peopel with full access versions can still use it too... but if your users would only have the runtime they would i.e. not be able to make new database or make changes to excisting ones.
 
I really need to write a tutorial on this type of thing for people here...I see this a lot.

Here is what I do.

I have a table with usernames and access levels. Upon login, this table is checked for the current user logged into the computer, and grants the proper access for that user. I use a custom menu which has different things enabled/disabled based on access level.

I disable shift keys (and in some cases, right clicking) and disable the normal menu. This leaves only the menu which I have control over available for use. Users cannot get into any options. I disable the normal access window with all the tables and such and just bring up a form on startup that has the DB name, version, etc.

I make this an MDE of course.

If I have some time, I will try to make a tutorial for people here.

Note - this works best in a secure networked environment. Barring that, you could have a form at startup with a username/password box instead.
 
Odin's approach is the best and easiest to implement. I'd do the same thing myself except that I'd just use User Level Security rather than a table containing usernames and access level.

The thing is that MDE does not encrypt any information, if you deign to use a table to store any sensitive information, it will be very easy to view those sensitive information by opening the MDE with a text editor. Same for VB constants.

In my case where I don't use ULS because I use different backend, I only store the salt, and prompt the user for password, then hash the password+salt to authenticate the user and providing strong security (e.g. user's password alone would not provide any access to the backend, and the algorithm I use to salt the password can be anything I want so it can't be just guessed outside of running the application itself, and MDE will encode the VB code for the algorithm.
 
Well there should be no local tables in the MDE file, save for maybe a table with version info. Other than that, it should all be links to the backend.
 
Gotcha- Yes, that will do just fine. Can't remember if clicking on the links directly will still open the table from backend anyway?

Any particular reason for not employing ULS?
 
I hate ULS? :P

I prefer to have more/easier control over things. The way I do it, since we are networked, users just open and they don't have to worry about passwords or anything.

Granted I have not used ULS much but it is MUCH easier to use my methods if you have a migration or other things and...well I'm used to it and it works well. I don't have to worry about workgroup files and such and I don't have to bother with the klunky interface. It's quicker. Just add a user, pick an access level in the table and you're done.

Also - users do only data entry work. They have no need to do anything other than enter or lookup data. Supervisors and higher have reports and tools for managing things like aging and employee productivity, etc. I do all the design work for forms and reports and queries - they have no need for that.

ULS may work better in an environment where some users need to be able to work with queries or something like that...but we don't need that here at all.
 
Last edited:
odin,

Quite understandable! They did a horrible job with ULS and the million threads asking about security is a testimonial to how confusing it can be to first-timers. I know it did confuse the hell out of me. Thanks for sharing your case model- I was curious about what scenarios where ULS just doesn't make sense, like in my case where I use MySQL as the backend, so the only thing I need to secure is the code, which MDE is quite dandy for the job.
 
I'd just like to clear up two points:
1. ULS is not supported for the new .accdb/.accde database formats. If you stick with the .mdb format, you loose many of the new features of A2007 but A2007 will run the ULS.
2. There is no such thing as a runtime version of your application. There is a runtime version of MS Access. When running your application with the appropriate runtime version of Access, the users do not have access to the database window or any feature of the application that modifies objects. All they can do is use the custom menu and forms you design to access the data and objects you expose. But the same application run with the regular MS Access .exe, is as exposed as you allow it to be.
 
Hi,

just a thought. if you are using 2007 ( which i guess you are), you can hide the options etc. on the start menu through ribbonx. this way, you could de-select the navigation options and so forth then hide all of the buttons through the ribbon which can be determined on start up. then if the buttons are not available, they cannot be used. this site is really useful for ribbon stuff. http://www.accessribbon.de/en/

NS

Hi Pat,
I am also worried about the user who may go to the Access Options and recheck the Navigation Pane. Does anyone know of a program you can buy that may be able to make a group of Forms in an Access file to absolutely stop this from occurring or any other way to do this?
Thank you,
 

Users who are viewing this thread

Back
Top Bottom