Any tips for automating "locking down" an mde?

  • Thread starter Thread starter google
  • Start date Start date
G

google

I am working on a database that I will developing while it's being
used. There are things I'd like to do to keep users out of areas they
shouldn't be in (such as disabling autoexec bypass, hiding the database
window, toolbars, etc.), but when I'm working on a database and
frequently saving it as an in-production mde, these things can be an
inconvenience for me. I keep the mdb on my local computer, then save
an mde of it to a shared network folder (which then gets copied
automatically to individual workstations by Tony Toews' Auto FE
Updater). I wanted to be able to update the whole process, so I could
have a hidden button that would programmatically set all these
attributes, save it as an mde, then switch them back in my mdb. But it
seems that the automated way of saving an mde can't be used on the
current database. Is there a command to determine whether or not the
current db is an mde vs. an mdb? Perhaps I could use that to set these
attributes, since I'm the only one who will be working in the mdb.

Anyone have any tips they want to share in making this a little easier?

Thanks!
 
No doubt you already have code that performs the "lock down" functions
you require. Conditionally check to see what type of file is running
and enable or disable your features as required.
Is there a command to determine whether or not the current db is an mde
vs. an mdb?

Select Case Right(CurrentProject.Name, 3)
Case "mdb"
MsgBox CurrentProject.Name & " is editable."
Case "mde"
MsgBox CurrentProject.Name & " is not editable."
Case Else
MsgBox CurrentProject.Name & " does not meet naming conventions."
End Select
 
You most certainly can, and should hide all of the ms-access interface. The
options to complete hide and keep people out of the ms-access interface can
easily be done using the tools->start-up options. Using those options allows
you to complete hide the ms-access interface (tool bars, database window
etc). Also, using these options means you do not have to bother setting up
security.

Try downloading and running the 3rd example at my following web site that
shows a hidden ms-access interface, and NO CODE is required to do
this....but just some settings in the start-up.

Check out:

http://www.members.shaw.ca/AlbertKallal/msaccess/DownLoad.htm

After you try the application, you can exit, and then re-load the
application, but hold down the shift key to by-pass the start-up options. If
want, you can even disable the shift key by pass. I have a sample mdb file
that will let you "set" the shift key bypass on any application you want.
You can get this at:

http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html

Of course, during development, you will hold down the shift key so your
startup settings don't run. You then develop for awhile, and then to test in
"user" mode, you exit..and then re-enter the application without the shift
key bypassed. You will likely do this dance all day long as you run/test as
user mode, and then flip back in to developer mode (shift key used..so you
don't get the main custom menu). So, you can't develop, or really modify
things when you run your application with the startup settings...so you must
shift-by-pass them when you want to work.

And, in fact, I use alt-f4 to exit the application...the mdb file should
still
be highlighted in the windows explore..so, then you hit enter key (and, hold
down shift key if you need be). This key stroke sequence and exiting and
re-entering the application will occur CONSTANTLY all day long when you
are developing. When you finally have things just right...you create the mde
you plan to distribute...
 
Not necessarily Anton. The extension can be changed. You can change mde to
mdb, but it's still a mde.

Function IsItMDE(dbs as Database) As Boolean
Dim strMDE As String
On Error Resume Next
strMDE = dbs.Properties("MDE")
If Err = 0 AND strMDE = "T" Then
'It's an MDE database.
IsItMDE = True
Else
IsITMDE = False
End if
End Function
 
You REALLY should not allow your users to have access to anything but
an MDE version. Here is how we control access to forbidden features
in the MDE:

ChangeProperty "StartupShowDBWindow", dbBoolean, False
ChangeProperty "StartupShowStatusBar", dbBoolean, True
ChangeProperty "AllowBuiltinToolbars", dbBoolean, False
ChangeProperty "AllowFullMenus", dbBoolean, False
ChangeProperty "AllowBreakIntoCode", dbBoolean, False
ChangeProperty "AllowSpecialKeys", dbBoolean, False
ChangeProperty "StartupShowDBWindow", dbBoolean, False
ChangeProperty "AllowShortcutMenus", dbBoolean, False

' Change this one to false just prior to MDE creation:
ChangeProperty "AllowBypassKey", dbBoolean, True

Here is the "ChangeProperty" Sub:

Function ChangeProperty(strPropName As String, varPropType As Variant,
_
varPropValue As Variant) As Integer
Dim dbs As Database
Dim prp As Property
Const conPropNotFoundError = 3270

Set dbs = CurrentDb
On Error GoTo Change_Err
dbs.Properties(strPropName) = varPropValue
ChangeProperty = True

Change_Bye:
Exit Function

Change_Err:
If Err = conPropNotFoundError Then ' Property not
found.
Set prp = dbs.CreateProperty(strPropName, _
varPropType, varPropValue, True)
dbs.Properties.Append prp
Resume Next
Else
' Unknown error.
ChangeProperty = False
Resume Change_Bye
End If
End Function

If you do the above in a basGlobal module, you users will not have
access to any of the forbidden objects.
 
Perhaps, it's worthwhile for others reading this thread to know that
there are those of us who do not in any way protect our applications
(not to be confused with protecting data).
I am one of those, always delivering a simple MDB file (once, once too
many actually, an ADP) with all code and objects visible and editable.
I have never had a problem as a result of this. I've toyed with the
idea of password protecting VBA projects but have yet to do so.
Why have I not had problems? I guess because the people with whom I do
business are honest and intelligent.
A couple of times IT has lost the application, and once removed all the
ISAMs. They were happy to pay my standard rate for recovery.
My basic contract generally restricts the client from making the
application available beyond his or her organization, but otherwise
gives him/her complete ownership, in so much as it does not restrict me
from using any part of the application in any way.
I never worry about being cheated; and I rarely am.
 
Perhaps, it's worthwhile for others reading this thread to know that
there are those of us who do not in any way protect our applications
(not to be confused with protecting data).
I am one of those, always delivering a simple MDB file (once, once too
many actually, an ADP) with all code and objects visible and editable.
I have never had a problem as a result of this. I've toyed with the
idea of password protecting VBA projects but have yet to do so.
Why have I not had problems? I guess because the people with whom I do
business are honest and intelligent.
Click to expand...

With "intelligent" being the pivotal issue. If you distribute ANY
application to the general public, one cannot depend on the honesty OR
intelligence of those who receive it. In a corporate setting, where
you know your users, and they all work in a structured, hierarchical
setting, exposing the MDB is usually safe. I did it for many years in
the corporate world and never had a problem because all users knew
that they were not to tamper with the objects and were loathe to do so
on fear of management reprisal. If you are non-employee, contracted
to deliver a corporate setting app, they SHOULD have the MDB because,
often, they literally OWN the code.
 
Lauren said:
With "intelligent" being the pivotal issue. If you distribute ANY
application to the general public, one cannot depend on the honesty OR
intelligence of those who receive it. In a corporate setting, where
you know your users, and they all work in a structured, hierarchical
setting, exposing the MDB is usually safe. I did it for many years in
the corporate world and never had a problem because all users knew
that they were not to tamper with the objects and were loathe to do so
on fear of management reprisal. If you are non-employee, contracted
to deliver a corporate setting app, they SHOULD have the MDB because,
often, they literally OWN the code.
Click to expand...

I've been brought in to recover internal apps that have been fiddled with..
a little knowledge is dangerous :) The most common thing is for users to
start adding their own reports... which only rarely works out.
 
Br@dley said:
I've been brought in to recover internal apps that have been fiddled
with.. a little knowledge is dangerous :) The most common thing is
for users to start adding their own reports... which only rarely
works out.
Click to expand...

Exactly. I don't distribute MDEs to protect myself or my code. I do it to
protect users from themselves. To the extent that it benefits me it is strictly
in the reduction of tech support calls.
 
Exactly. I don't distribute MDEs to protect myself or my code. I do it to
protect users from themselves. To the extent that it benefits me it is strictly
in the reduction of tech support calls.
Click to expand...

Precisely!
 
"If you do the above in a basGlobal module, you users will not have
access to any of the forbidden objects."

Thank you for the code Lauren, that is very helpful. But I'm not
familiar with a "basGlobal" module. Is that a "special" module name
like autoexec that runs automatically, or is it simply the name of the
module where you've placed your code?

Thanks again!
 
"there are those of us who do not in any way protect our applications
(not to be confused with protecting data).
.... Why have I not had problems? I guess because the people with whom I
do
business are honest and intelligent."

Just for clarification, this is not a database I am developing to sell,
but one that I'm working on for use within the company I work for. I'm
not concerned with protecting my intellectual property... it's
technically not even mine - it belongs to my company. There was a
(rather feeble) database here before I started, and there have been
problems with people snooping around in areas they shouldn't have been.
The structure of the front-end mde is there to both restrict open
access of data users shouldn't have access to (such as through RWOP
queries), as well as to ensure that they are working with data THROUGH
the code, which has all of the safeguards to ensure that the data is
getting entered correctly. I don't really follow how you separate
protecting data from protecting the application, since compromising the
application can result in compromising the data.

You expose your application because you trust your users. I lock down
the application because I KNOW the users. ;-)
 
I don't wish to criticize the value of MDEs nor setting the StartUp and
Allow Properties to False for unsophisticated users. But I think our
readers should not think that this procedure is some kind of absolute
security. It is not.
A capable developer/hacker would reverse all the property settings and
recreate all the Access Objects (except actual code) in an hour; he/or
she would make inferences about the code and produce parallel code; the
time for this would depend, of course, upon how much code there is.

The reason that MDEs are not regualraly hacked may be that those who
have the skill to do so are ethical and, more often than not, don't
want what's inside.
 
Lyle Fairfield said:
I don't wish to criticize the value of MDEs nor
setting the StartUp and Allow Properties to False
for unsophisticated users. But I think our readers
should not think that this procedure is some
kind of absolute security. It is not.
Click to expand...

Agreed. They are to prevent users from stumbling over their own fingers.
It's not really "security" at all.
A capable developer/hacker would reverse all
the property settings and recreate all the Access
Objects (except actual code) in an hour; he/or
she would make inferences about the code and
produce parallel code; the time for this would
depend, of course, upon how much code there is.
Click to expand...

Most Access databases I have observed don't have a great deal of code -- I
guess the developers were happy to "let Access do it" if they knew "the
Access way." Exceptions have been databases created by "refugees from some
other language", which tended to be mostly unbound, and the code looked
surprisingly like typical code from "the other language".
The reason that MDEs are not regualraly hacked
may be that those who have the skill to do so are
ethical and, more often than not, don't want
what's inside.
Click to expand...

Those who are "hacker-level" in Access may "re-generate" better code that
the original developer, for that matter. Most of the client databases I have
developed or modified were so client-specific that they wouldn't have found
a ready market if hacked or reproduced.

The "heavy lifting" is often in applying Access (or, computer techniques in
general) to the business problem. And that is usually evident from observing
the application execute.

Larry Linson
Microsoft Access MVP
 
Honestly, the only reason I started developing in Access in the first
place was because I had seen the power of a very simple, yet very
robust, VB application at work. Watching it do what it did, I learned
quickly in Access, that I could do similar things and make very good
applications to improve efficiency and reduce replication of work. Had
I not seen that, I wouldn't be here now.

That said, the very first Access DB I put together (relying in large
part on macros and some really bassackwards code, and not properly
normalized because I didn't know what that meant then) is still running
fine 4 or so years after I left it behind in Hawaii. I did secure it
with the built-in security wizard, but only insofar as it kept folks
away from the tables (which they had been editing directly in the
database that it replaced) and forced them to use the forms. There was
nothing to keep them out of the code, or design mode for that matter,
and like I said, it's still working fine, fumbling fingers and all.
Since then, I've developed others, a database that administers yearly
exams for qualifications, for example, that had to have some serious
"slacker" proof code. It doesn't use any of the built-in security, and
is only secured as above in Lauren's example requiring a login
referencing a Users table. I say "slacker" here because, in this case,
we aren't talking about folks who are interested in any sort of
intellectual property asside from the answers to the exams to save them
some time in looking the answers up or reflecting their poor knowledge
of the subject matter in the form of failing and having to retake
exams. That DB is far from impenetrable, but those with the knowledge
to do so, don't really care to cheat on an exam, and are more
interested in howstuffworks. There's a fine line between tampering and
hacking, but if your end product isn't useful (read expansive, beyond
your development of the initial offering) it doesn't do your company a
whole heap of good and is no longer a living document, which is really
all a database is.
 
"If you do the above in a basGlobal module, you users will not have
access to any of the forbidden objects."

Thank you for the code Lauren, that is very helpful. But I'm not
familiar with a "basGlobal" module. Is that a "special" module name
like autoexec that runs automatically, or is it simply the name of the
module where you've placed your code?

Thanks again!
Click to expand...

Honestly, I'm not completely clear on how Access processes a module
specifically named "basGlobal" -- if it does so in any way different
from any other module name. All I know is that I have been using one
in all apps for years and that is where I place all global variables
and API declarations. Somehow, a miracle occurs and it all works!
Perhaps someone else here can elaborate on the alleged utility of this
approach better than I.
 
Back
Top