I have the following code on my form on the on_open
Dim PassWord As String
PassWord = InputBox("Enter Password")
If PassWord = "1234" Then
'Open Form
Exit Sub
Else
MsgBox ("You're not authorized.")
DoCmd.Close acForm, Me.Name
End If
The problem I have is, if the user doesn't enable content the password box doesn't kick in.
Is there an alternative solution so it will always ask for a password whether the enable content is clicked or not?
The content the user has to enable is the executing of macros and code, so this way of protecting your database will only ever work when all users have done that.
And even if they have enabled it, they can easily circumvent it by shift-doubleclicking your database to open it without executing any code at all.
There are a couple of ways to protect your database with a password:
Choose File -> Info -> Encrypt database. This will allow you to use a single password to encrypt your entire database. It'll do pretty much the same thing as you have now in your code, only safer.
File -> Save As -> Make ACCDE. This will turn your database into an executable-only file. This also means you can no longer make any changes to your database structure! You should split front-end and back-end and keep a development copy of your front-end which you can push out to your users whenever you made any changes.
Create a macro with name AutoExec
When a database starts, Access runs the AutoExec macro before it runs any other macros or VBA code.
AutoExec macro has following Condition & Action
This will run before the macro is enabled.
Not recommended way as it can be easily bypassed by users.
Related
So after some digging I realize that there is no built in user level security option for Access 2007. What I need to do is restrict records that users can edit based on who is logged in (they can see all the data but only edit their own). I was thinking that I could make a log in form and assign passwords and go from there, but I was wondering if there was a better method to do this.
For user privileges for read-only, read-write on forms in the database, we implemented following tables, logic.
I created a privilege table along with log-in table. Each screen in the database will have Read-only or Read-write privilege to each user. I inserted all the screen names into privilege table. Another table UserPrivilege will have users and their privileges. Assigning privilege to an user will be done only by Admin user.
A function at start of each form check swhether a specified user is allowed to view or edit form. If he/she is given read-only, we will lock all controls looping thr' controls on the form. Else, nothing to do. OR keep all the controls read-only at design them and unlock them thr' code for write privilege.
The database window is kept hidden when a version to end user is delivered. This prevents usual , simple view to tables in the database, opening forms , reports object in database window. After making mde/accde few more tweaks can be done so that user is not easily able to view tables directly. by-passing startup, special keys etc.
I have been facing this problem too. My solution (which hasn't been broken yet) is to do exactly that. Make a user's table with passwords and a log in form which reads the table for User name, password and user type. I have used two ways to proceed from there: Case statement to open specific navigation forms for that user's functions or a global variable (in a module (enumeration helps)) and an getter function that is checked within each form's open events and changes properties like AllowEdits, and AllowAdditions and even cancel the form opening if it's administrative stuff.
The most important part of this set up is making sure the users are using Access Runtime. If they use the Access version you are developing in they can snoop a little bit and get around this.
Make sure you hide the user's table.
Access runtime can be forced by making a shortcut to the DB and adding /runtime to the end of the shortcut path (with a space).
It's not perfect, but it works for my purposes and It might work for your's.
I did dot this in 2010, but 2007 should be pretty much the same.
Assigning username/passwords in Access (especially with an access back end) has a number of critical issues that are worth pointing out. Firstly, if you don't encrypt your DB, then any of your users who are savvy enough to go looking for it will be able to find it, and therefore get full access to it. If you encrypt the DB, if anyone can get access to your source code you're toast, since they will be able to see the DB user/passwords stored in the code. This issue persists if you use other SQL db's, but at least in those cases you can restrict the user supplied to the Access .accdb file to have certain permissions.
For my case, I have 3 levels of security. Firstly, I heavily restrict what I send out to make it very difficult to access the source code, which you kind of have to do no matter what. Secondly, I distribute different levels of access with different DB passwords (I'm using a MySQL back-end, you could do the same with a SQLServer back-end, but with Jet you're out of luck), so even if users could see the DB user and password, they are limited in what they can do. Thirdly, since I deploy on a corporate network, I take advantage of windows groups, and use those to filter out what is visible to different users. That way, users can only use the forms if they are authenticated onto our network. If the file discovers it's not on the network, it deletes itself and terminates.
Function IsMember(strDomain As String, strGroup _
As String, strMember As String) As Boolean
Dim grp As Object
Dim strpath As String
strpath = "WinNT://" & strDomain & "/"
Set grp = GetObject(strpath & strGroup & ",group")
IsMember = grp.IsMember(strpath & strMember)
End Function
Function GetCurrentUser() As String
GetCurrentUser = VBA.Environ$("USERNAME")
End Function
Function GetCurrentDomain() As String
GetCurrentDomain = VBA.Environ$("USERDOMAIN")
End Function
I have constructed a database using MS Access 2007. When opening the database, a form automatically pops up and covers the entire screen for the user to enter data. However, if the admin wishes to change anything in the tables, queries or forms behind this form, they would hit the admin button on the form which prompts them to enter a password. If the password is correct, the form will close and they're free to make any necessary adjustments. If the password is incorrect, the form will not close and their only option is to close the application altogether. The VBA code I have works, however how can I encrypt the text the user is typing? Here is the VBA Code
Private Sub cmdAdmin_Click()
Dim password As String
password = InputBox("Please enter the password")
If password = "passw0rd4" Then
DoCmd.Close
Else
MsgBox ("Sorry, access denied!")
End If
End Sub
All input is welcomed. Thank you!
The input box does not have an option for you to mask the characters/hide the data entry. Make a form with a text box and set the input mask for the textbox to be PASSWORD. This should accomplish what you need/want.
My quick "code free" solution is to use Font Name "Wingdings" for the password field. The occasional passer-by will not be able to read it; however, if you live in an hacker-rich environment, you definetly need a code solution, which unfortunately I cannot give...
I created a form in MS Access. Unfortunately I cannot publish to access services or make a package solution
I am looking for a user friendly way to present this form to the user. So far the user will open the ms access file , click on the form and fill it out.
I would like to have a way to provide the form ONLY. I do not want the user to see all the tables and the structure . . Is there any way i can separate the form from the tables, queries etc. list ?
I split the database, and gave a fe copy to the user, but it still sucks! All those panels and stuff. Does MS Access has anything to address this issue ?
The issue(s) of splitting the database, and the issues of creating a compiled accDE are NOT ONE BIT RELATED to hiding the Access interface.
100% separate question and issue.
Now, without question the above should be done for any access application, but THE ABOVE HAS ZERO TO DO WITH hiding the access interface.
Once you get the access UI hidden, then you can consider the idea of compile to accDE a good idea to PREVENT users from getting into the access UI parts.
Same goes for splitting. You really need to split. However, AGAIN the splitting has NOTHING to do with hiding the accsss interface.
So now, lets get on to hiding the access interface.
To hide all of the access interface and ONLY show the form, you need to add ONE LINE to your start up code (the forms on-load event is fine).
So, specify the form you want to display in the options.
Add this ONE LINE of VBA code to the forms on-load event.
DoCmd.ShowToolbar "Ribbon", acToolbarNo
The additional settings you require are:
[x] Display Navigation Pane <-- uncheck this box.
[x] Use Access Special Keys <-- uncheck this box
Set access to use tabbed interface, and un-check the box to display tabs.
The form MUST NOT be popup. It can be model, but NOT popup.
The result is you will ONLY see the form. This shows the result:
Now keep in mind to get back to "developer" mode, you have to exit, and then hold down the shift key during startup. When you get all of this working, then you want to compile to an accDE, and search out some answers on how to disable the shift key during startup to prevent your users from seeing the access UI.
So you ONLY need one line of code to achieve this goal. The rest is just choosing the correct settings in your application, and that one line of code on startup.
Steps for publishing the compiled accde file and making it ready for end user:
BackUp: Take backup of your accdb/mdb file
Uncheck following elements from Database Options
(Office Button=>Access Options=>Current Database) :
Display Navigation Pane
Allow Full Menus
Allow Default Shortcut Menus
Security: To prevent anyone bypassing the start-up by using the Shift key and access the table use below code :
Public Function DisableByPass()
On Error GoTo err_proc
'Disable By Pass Key in mde/accde db
Dim dbs As DAO.Database
Dim prp As Property
Dim strMDE As String
Set dbs = CurrentDb
With dbs
On Error Resume Next
strMDE = .Properties("MDE") 'If this is an MDE or ACCDE database, disable bypass key
If Err = 0 And strMDE = "T" Then
.Properties("AllowByPassKey") = 0
If Err.Number = 3270 Then
On Error GoTo err_proc
Set prp = .CreateProperty("AllowBypassKey", dbBoolean, False)
.Properties.Append prp
.Properties.Refresh
End If
End If
End With
exit_proc:
On Error Resume Next
dbs.Close
Set dbs = Nothing
Exit Function
err_proc:
MsgBox Err.Description
Resume exit_proc
End Function
I'm trying to input some code that hides "Design View" as an option for our internal application unless a certain permission requirement is met.
The following code works with one exception:
On Error Resume Next
If Not GetUserInfo("ADMIN_PERMIS") = 1 Then
Dim cb As CommandBar
Dim cbCtl As CommandBarControl
For Each cb In CommandBars
If cb.type = msoBarTypePopup Then
For Each cbCtl In cb.Controls
If cbCtl.Caption = "&Design View" Then
cbCtl.enabled = True
cbCtl.visible = False
Else
cbCtl.visible = True
End If
Next
End If
Next
Set cb = Nothing: Set cbCtl = Nothing
End If
The one problem with this is that it disables Design View not only for the current database, but also for any other access database that is launched. I'm looking for a way to try and apply this code in such a way that it only affects the Access database I have the code in and not in every single instance of it.
I recommend converting the database into a compiled, executable only .accde file (File --> Save & Publish --> Make ACCDE). Doing this will prevent any design or code changes in the application. Keep a development version in the normal .accdb format. Make your changes there and then compile into the .accde version for each update.
Since your team updates the database often, you could benefit from using Peter De Baets' database starter. The database starter makes a local copy of the front end of the database, allowing uses to continue to work while design changes are being made. After the production accde front end file is updated, the users will automatically copy the new file the next time they open the database. In my office I have found that I can push out a quick fix and simply email everyone saying "Close and reopen the database guys!".
All these answers are great. If you are interested in the simplest method, I found the form holds the key, albeit in a strange spot.
In the forms properties->Other Tab->Shortcut Menu =No
Our MS Access 2000 developer left the company a year ago. We need to open his app in design mode in order to make modifications. Double-clicking the .mdb file while holding the shift key doesn't work. When I do that the developer toolbar shows for a split second, then all toolbars go away and the app opens as users would see it. No toolbars show and only a basic dashboard is visible to run the app. I tried using the password recovery tool mentioned here but the tool says there is no password. Can someone tell me how I can open this app to make code modifications?
Beth's answer worked for myself and a co-worker. I've copied the solution here from the link in case the link dies.
"...To unlock the Access DB you can use the following if you know the full path to your database.
Copy the following function into a module in ANOTHER database and call the function. You will need to set the strPath to the path of your database."
Public Function ResetExternalDatabaseBypassKey _
(Optional tfAllow As Boolean = True)
'Name: ResetExternalDatabaseBypassKey (Function)
'Purpose: Sets AllowByPassKey to true in another Access Database
'Author: John Spencer UMBC-CHPDM
'Date: May 02, 2000, 12:08:19 PM
'*******************************************
Dim dbs As Database
Dim strPath As String
On Error GoTo ResetExternalDatabaseBypassKey_ERROR
strPath = "C:/MyDatabases/SomeDataBaseName.mdb"
Set dbs = DBEngine.Workspaces(0).OpenDatabase(strPath)
dbs.Properties("AllowByPassKey") = tfAllow
ResetExternalDatabaseBypassKey_ERROR:
Select Case Err.Number
Case 3270 'Property not found
MsgBox "Allow Bypass Key property does not exist " & _
"for the chosen database."
Case Else
MsgBox Err.Number & ": " & Err.Description
End Select
End Function
Make sure there wasn't another copy left around without this code enabled.
This is typical code used to do this sort of thing, SetByPass There are instructions to hit Cntl-G to open VBA Editor and run code to unset this thing.
Have you tried creating a new blank database, and then importing everything?
It sounds like the shift key by-pass has been set, but that's as noted usually only needed for deployment. In fact, for any access developer, this is quite much a standard approach.
So, it not clear if anything at all been locked up here or the person just set things up as most access applications should be when deployed to users.
About the only thing you lose when importing to another application is the tools startup settings and the shift key. If there are custom menus, make sure you check the option to import those also. (However, be careful, as sometimes custom menus can be setup to run a macro on startup, and this was an old security trick). So, if importing once with tool bars and holding down shift key still causes startup code to run, then try creating another blank database and this time import everything except the menu+tools bars from the old application. Holding down shift key will thus then work for you.
Also, if the system not asking your for a password, then what would you expect a password recovery program to do? All you need is basic access developer skills here to deal with this problem and throwing things like password removal when you not being prompted for passwords will not move you forward here.
On the other hand, if after importing all the forms into a new database the design ability is grayed out, then this was in fact a mde file, and you are in a rather difficult situation unless you can find the original mdb file used to create the mde.