AllowBypassKey

  • Thread starter Thread starter Lori
  • Start date Start date
L

Lori

I need someone's step by step help for a beginner on how
to set the AllowBypassKey property to false (so the bypass
shift keys don't work at time of startup). I have tried
several different codes, including MS's
CurrentProject.Properties.Add "AllowBypassKey", False.
Nothing seems to work, still can reopen with shift keys.

Obviously I don't know how or where to write the correct
code correctly. I've read that you open the VB editor in
the immediate window and type it. But where does it save
it to (under general?), not an event linked to a form?
I've seen Public sub mentioned, I've seen things like you
have to append or create a new property to add to the
properties collection (don't know how to do that). I've
seen where you can create or change a AutoExec macro, but
not sure how or what to do there.

Can someone, please give me the correct code to use, plus
step by step instructions on where and how I do the steps
to set this up?

Thanks so much! Can email me at (e-mail address removed)12.WI.US
 
This is one nice utility.

Appears to me it can be run externally on any database and flip the status
of the bypass key.

How do I prevent someone from running this against my Access database and
changing the status and opening up the code?

Gary D
 
Gary Dikkema said:
This is one nice utility.

Appears to me it can be run externally on any database and flip the status
of the bypass key.

How do I prevent someone from running this against my Access database and
changing the status and opening up the code?

Gary D
Click to expand...

I suppose you could make sure people don't distrbuite the utiliaty!

The other sotlion is to secure your database. Then, only a user with admin
proviacles can run my code (in fact, you would need to modify my code
exmaple to prompt for the user name). If I get any more requests...I will
add such a feature...but it does mean that you will have to profice a user
name and password to change a secured database.
 
AFAIK, only a member of the Admins group *of the workgroup file that was
used to create the database*, can change the values of properties that were
created with the CreateProperty DDL parameter set to True. So, I doubt that
a user of the Admins group of any *other* workgroup file, could change that
property, if it was created with DDL = true. Try it & see.

HTH,
TC
 
Sorry guys!

Missed that subtlety and it's the key to my question.

Read somewhere that it would take a week or two (or more) to understand
Access security. After spending the past few days and tinkering an awful lot
with backup Access databases I think I understand it.

One thing still left to understand.

Is RWOP really that important now that I have taken away the ability for
someone unauthorized to see the code?

A day or so I would have said this would be critical, but now I do not think
so.

I know that I had to give full permissions to users so that macros and
queries that empty or delete tables would run.

TIA.

Gary D
 
Gary Dikkema said:
Is RWOP really that important now that I have taken away the ability for
someone unauthorized to see the code?

I know that I had to give full permissions to users so that macros and
queries that empty or delete tables would run.
Click to expand...


Using RWOP you wouldn't have to give users any permissions on the tables.
 
Joan,

My application is based on heavy use of queries and macros.

As such I find I need to give my main user the following accesses... full
data, new data users and update data users.

With that, if anyone were to break in, they have view access to most
objects... tables, queries and modules.

All I've secured is the forms and reports and macros.

If I have overlooked something please correct me. Thanks.

I am using that nifty little utility that PREVENTS the bypass process from
working so my content should be secure... no?

Gary D
 
Gary said:
My application is based on heavy use of queries and macros.

As such I find I need to give my main user the following accesses...
full data, new data users and update data users.
Click to expand...

You should not need to give the users *any* permissions on the tables, if
you use RWOP queries (this assumes that the owner of the query has full
permissions on the tables). The RWOP queries will need the appropriate
permissions (at least read data) for users to open and use the query, but no
permissions are necessary on the tables.
 
I'm a little confused now Joan...

I followed the Security FAQ...

RWOP is set in the Options yes? If so, I have set it to Owner and not User.

And I've gone into the Security for Users and Group accounts...

And if I change my main user account to just a User it has no access to even
open the database.

The only way it works, from what I have seen, is to five it New data User,
Full Data and Update Data rights...

What am I missing Joan?
 
I want to retract this post.

For some reason, I have been able to flip the bypass status using any User
account. It's not restricted to admins... but IMO, it should be.

And the info that I read inside this nifty utility says ANYONE who can open
the database can run this.

So how hard would it be to ONLY allow admins users to run this utility? Lots
of work to make it only do this?

Gary D
 
My findings in Access 2003 shows *ANY* user of that Workgroup can at will
flip this Bypass bit.

Gary D
 
Sorry to flood you on this matter...

Here's an inline comment... a direct quote.

' The current listing in Access help file which will
' let anyone who can open the db delete/reset any
' property created by using this function, since
' the call to CraeteProperty doesn't use the DDL
' argument
'

Seems to me this will open any and all Access tables.

That is not a good idea IMO.

Gary D
 
Hi Gary,

Gary said:
RWOP is set in the Options yes? If so, I have set it to Owner and not
User.
Click to expand...

You wouldn't just set this in Tools, Options - that setting would cause any
new queries you make (after setting it) to default to Owner. For your
existing queries, you must open each one, go to View, Properties, and set
Run Permissions to Owner's.
And if I change my main user account to just a User it has no access
to even open the database.
Click to expand...

Not sure why you would do this. Open Tools, Security, Permissions, choose
groups, choose your RWOP query and set read data permissions. If your users
need to update, insert or delete data using the RWOP query, then give them
those permissions as well *on the query*.

No permissions are needed on the tables.
 
Hi Gary,

The utility you are using doesn't use the fourth argument, and therefore any
user can flip it back.

Here's the function I use:
<start>
Public Function tsi_DisableShiftKeyBypass()
'code courtesy of Michael Kaplan
'The next time the database is opened after this function has been run,
' the autoexec macro will not be bypassed, even if the shift key is pressed.

On Error GoTo errDisableShift

Dim db As Database
Dim prop As Property

Set db = CurrentDb()

' Ignore the error removing this prop, in case it does not actually
exist
On Error Resume Next
db.Properties.Delete "AllowByPassKey"
On Error GoTo errDisableShift

'The AllowBypassKey property is a user-defined property of the
'database that must be created before it can be set. You must set
'the DDL param to make sure that only people with the right perms
'can change this prop later
Set prop = db.CreateProperty("AllowByPassKey", dbBoolean, False, True)
db.Properties.Append prop
tsi_DisableShiftKeyBypass = True

exitDisableShift:
Exit Function

errDisableShift:
MsgBox "Function DisableShiftKeyBypass did not complete successfully."
tsi_DisableShiftKeyBypass = False
Resume exitDisableShift

End Function
<end>

Put that into any module in your database. While logged in as a member of
the Admins group, hit Ctrl-G and type
tsi_Disableshiftkeybypass

Close your database, and re-open - the shiftkey will be disabled. Only a
member of the Admins group can set it back (and only from another mdb).
 
Thanks Joan!

I am beginning to think I had the correct permissions to begin with. <VBG>
 
Will give this a whirl!

Presume that Utility will then work if I login as an Admin user.

Thanks so much!

Gary D
 
THANK YOU SO VERY MUCH!

So Joan... let me snip a lot of the good stuff here...

Now that Utility only works if I use an Admins member with the proper
password.

However, you mention setting it back from another MDB, not sure how you
mean. I'm sure that the proper password for an Admins will be required, but
could you tell me more?

Sorry but I don't quite get it!

Gary D
 
It is very rare that I ever need to set it back. I usually create a mde;
open the mde and set startup options, disable the shiftkey and distribute.

If I need to change something, I'm doing that in the original mdb where the
shift key isn't disabled.

But you can, if you need to, set it back from another mdb.

Use the same function with a few modifications:

You'd need to add
Dim wrk As Workspace
then
Set wrk = DBEngine.Workspaces(0)
and change the Set db statement to
Set db = wrk.OpenDatabase("path to mdb")

Then change this line
Set prop = db.CreateProperty("AllowByPassKey", dbBoolean, False, True)
to
Set prop = db.CreateProperty("AllowByPassKey", dbBoolean, True, True)

To use this on your secure mdb, you'd need to open it using your secure mdw
and logging in as a member of the Admins group.
 
Perfect!

Thanks so much.

Gary D


Joan Wild said:
It is very rare that I ever need to set it back. I usually create a mde;
open the mde and set startup options, disable the shiftkey and distribute.

If I need to change something, I'm doing that in the original mdb where
the
shift key isn't disabled.

But you can, if you need to, set it back from another mdb.

Use the same function with a few modifications:

You'd need to add
Dim wrk As Workspace
then
Set wrk = DBEngine.Workspaces(0)
and change the Set db statement to
Set db = wrk.OpenDatabase("path to mdb")

Then change this line
Set prop = db.CreateProperty("AllowByPassKey", dbBoolean, False, True)
to
Set prop = db.CreateProperty("AllowByPassKey", dbBoolean, True, True)

To use this on your secure mdb, you'd need to open it using your secure
mdw
and logging in as a member of the Admins group.
Click to expand...
 
Back
Top